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Guide to the Manual 
This document serves both as a reference manual! and as an introduction to Argus. Sections 1 through 
3 present an overview of the language. These sections highlight the essential features of Argus. 
Sections 4 through 15 and the appendices form the reference manual proper. These sections describe 
each aspect of Argus in detail, and discuss the proper use of various features. Appendices | and II 
provide summaries of Argus’s syntax and data types. Appendix {ll summarizes some of the pragmatic 
rules for using Argus. 


Since Argus is based on the programming language CLU, the reader is expected to have some 
familiarity with CLU. Those readers needing an introduction to CLU might read Liskov, B. and Guttag, J., 
Abstraction and Specification in Program Development (MIT Press, Cambridge, 1986). A shorter 
overview of CLU appears in the article Liskov, B., ef a/., “Abstraction Mechanisms in CLU" (Comm. ACM, 
volume 20, number 8 (Aug. 1977), pages 564-576). Appendix IV summarizes the changes made to 
Argus that are not upward compatible with CLU. 


An overview and rationale for Argus is presented in Liskov, B. and Scheifler, R., “Guardians and 
Actions: Linguistic Support for Robust, Distributed Programs" (ACM Transactions on Programming 
Languages and Systems, volume 5, number 3 (July 1983), pages 381-404). 


The Preliminary Argus Reference Manual appeared as Programming Methodology Group Memo 39 in 
October 1983. Since that time several new features have been added to the language; the most 
significant of these are closures (see Section 9.8), a fork statement (see Section 10.4), equate modules 
(see Section 12.4), and a more flexibie instantiation mechanism (see Section 12.6). An eariier version of 
this document appeared as Programming Methodology Group Memo 54 in March 1967; this version is 
essentially identical, except that the locking policy for the built-in type generator atomic_array has been 
simplified. 


We would greatly appreciate receiving comments on both the language and this manual. Comments 
should be sent to: Professor Barbara Liskov, Laboratory for Computer Science, Massachusetts Institute 
of Technology, 545 Technology Square, Cambridge, MA 02139. 


The authors thank all the members of the Programming Methodology group at MIT for their help and 
suggestions regarding the language and this manual, with special thanks going to Elliot Kolodner, 
Deborah Hwang, Sharon Perl, and the authors of the CLU Reference Manual. 
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Though her unhappy rival was hers to keep 
Queen Juno aiso had a troubled mind: 

What would Jove turn to next? Better, she thought, 
To give the creature to Arestor's son, 

The frightful Argus whose unnatural head 
Shone with a hundred eyes, a perfect jailer 
For man or beast: the hundred eyes took tums 
At staring wide awake in pairs, and two 

At falling off to sleep; no matter how or 

Where he stood he gazed at lo; even when 
His back was turned, he held his prisoner 

In sight and in his care. 


— Ovid, The Metamorphoses, Book 1 
Tranetated by H. Gregory 
The Viking Press, Inc., New York, 1958 


Variables in guardian modyles can be declared to be atubie. 
survive crashes (see Section 2) and are. called sinhle oijpcis. 
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1.2. Assignment and Calis 

The basic events in Argus are assignments and calls. The assignment statement x ‘= E, where xis a 
variable and E is an expression, causes x to denote the object resulting from the evaluation of E. The 
object is not copied. 


A call involves passing argument objects from the caller to the called routine and returning result 
objects from the routine to the caller. For local calls, argument passing is defined in terms of assignment, 
or call by sharing; for remote calls, call by value is used. In a jocal call, the forma! arguments of a routine 
are considered to be local variables of the routine and are initialized, by assignment, to the objects 
resulting from the evaluation of the argument expressions. in a remote call (see Section 2.3), a copy of 
the objects resulting from the evaluation of the argument expressions is made and transmitted to the 
called handier or creator (see Section 2.4). These copies are then used to initialize the formal arguments 
as before. Local objects are shared between the caller and a called procedure or Kerator, but local 
objects are never shared between the caller and a called handier or creator. 


1.3. Type Correctness 

The declaration of a variable specifies the type of the objects which the variable may denote. In a legal 
assignment statement, x := E, the type of the expression E must be included in the type of the variable x. 
Type inctusion is essentially equality of types (see Section 12.6), except for routine types. (A routine type 
with fewer exceptions is included in an otherwise identical routine type with more exceptions. See 
Section 6.1 for details.) 


Argus is a type-safe language, in that it is not possible to treat an object of type 7 as if t were an object 
of some other type S (the one exception is when T is a routine type and S includes 7). The type safety of 
Argus, plus the restriction that only the code in a cluster may convert between the abstract type and the 
concrete representation (see Section 12.3), ensure that the behavior of an object can be characterized 
completely by the operations of its type. 


1.4. Rules and Guidelines 

Throughout this manual, and especially in the discussions of atomicity, there are pragmatic rules and 
guidelines for the use of the language. Certain properties that the language would like to quarantee, for 
example that atomic actions are really atomic, are difficult or impossible for the language to guarantee 
completely. As in any useful programming language, programmers have enough rope to hang 
themselves. The rules and guidelines noted throughout the manual (and collected in Appendix IH) try to 
make the responsibilities of the language and the programmer clear. 


1.5 Program Structure 5 


1.5. Program Structure 

An Argus distributed application consists of one or more guardians, defined by guardian modules. 
Guardian modules may in tum use all the other kinds of modules that Argus provides. Argus 
programmers may also write single-machine programs with no stable state, using Argus as essentially a 
“concurrent CLU." Such programs may be used to start up multi-guardian applications. Each module is a 
separate textual unit, and is compiled independently of other modules. Compilation is discussed in 
Section 3. 
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2. Concepts for Distributed Programs 

In this chapter we present an overview of the new concepts in Argus that support distributed programs. 
In Section 2.1, we discuss guardians, the module used in Argus to distribute data. Next, in Section 2.2, 
we present atomic actions, which are used to cope with concurrency and failure. In Section 2.3 we 
describe remote calls, the inter-quardian communication mechanism. in Section 2.4 we discuss 
transmissible types: types whose objects can be sent as arguments or results of remote calls. Finally, in 
Section 2.4 we discuss orphans. 


2.1. Guardians 

Distributed applications are implemented in Argus by one or more modules catied guardians. A 
guardian abetraction is a kind of data abstraction, but k differs from the data abstractions supported by 
Clusters (as found in CLU). In general, data abstractions consist of a set of operations and a set of 
odjects. In a cluster the operations are considered to belong to the abstraction as a whole. However, 
guardian instances are objects and their handiers are thelr operations. Guardian abstraction is similar to 
the data abstractions in Simula and Smaiitalk-80; quardiane are like class instances. 


A node is a single physical location, which may have multiple processors. A guardian instance resides 
at a single node, although a node may support several guardians. A guardian encapsulates and controls 
access to one or more resources, such as data or devices. Access to the protected resource Is provided 
by a set of operations called handlers. internally, a quardian consists of a collection of data objects and 
processes that can be used to manipulate those objects. In general, there will be many processes 
executing concurrently in a guardian: a new process is created to execute each handler call, processes 
may be explicitly created, and there may be other processes that carry out background activity of the 
guardian. 


The data objects encapsulated by a guardian are loca: they cannot be accessed directly by a process 
in another guardian. In contrast, guardians are global objects: a single guardian may be shared among 
processes at several different guardians. A process with a reference to a quardian can call the guardian's 
handlers, and these handlers can access the data objects inside the guardian. Handier calls allow access 
to a guardian's local data, but the guardian controts how that data can be manipulated. 


When a node fails, it crashes. A crash is a “clean” failure, as opposed to a "Byzantine" failure. A 
guardian survives crashes of its node (with as high a probability as needed). A guardian’s state consists 
of stable and volatile objects. When a quardian’s node crashes, all processes running inside the guardian 
at the time of the crash are lost, along with the guardian's volatile objects, but the guardian's stable 
objects survive the crash. Upon recovery of the guardian's node, the guardian runs a special recovery 
process to reconstruct its volatile objects from its stable objects. Since the volatile objects are lost in a 
crash, they typically consist only of redundant data that is used to improve performance (for example, an 
index into a database). The persistent state of an application should be kept in stable objects. 


Guardians are implemented by guardian definitions. These define: 
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1. The creators. These are operations that can be called to create new guardian instances 
that perform in accordance with the guardian definition. 


2. The guardian's stable and volatile state. 
3. The guardian’s handlers. - 


4. The background code. This is code that the guardian executes independent of any handier 
Calls, for example, to perform some periodic activity. 
5. The recover code. This is code that is executed after a crash to restore the volatile objects. 
Guardians and guardian definitions are discussed in Section 13. 


2.2. Actions 

The distributed data in an Argus application can be shared by concurrent processes. A process may 
attempt to examine and transform some objects from their current states to new states, with any number 
of intermediate state changes. Interactions among concurrem processes can leave data in an 
inconsistent state. Failures (for example, node crashes) can occur during the execution of a process, 
raising the additional possibility that data will be left in an inconsistent intermediate state. To support 
applications that need consistent data, Argus permits the programmer to make processes atomic. 


We call an atomic process an action. Actions are atomic in that they are both serializable and 
recoverable. By serializable, we mean that the overall effect of executing muttiple concurrent actions is 
as if they had been executed in some sequential order, even though they actually execute concurrently. 
By recoverable, we mean that the overall effect of an action is “all-or-nothing:” either ail changes made to 
the data by the action happen, or none of these changes happen. An action that completes ail its 
changes successfully commits; otherwise it aborts, and objects that it modified are restored to their 
previous states. 


Before an action can commit, new states of all modified, stable objects must be written to stable 
storage’: storage that survives media crashes with high probability. Argus uses a two-phase commit 
protocol’ to ensure that either all of the changes made by an action occur or none of them do. If a crash 
occurs after an action modifies a stable object, but before the new state has been written to stable 
Storage, the action will be aborted. 


2.2.1. Nested Actions 
Actions in Argus can be nested: an action may be composed of several subactions. Subactions can be 
used to limit the scope of failures and to introduce concurrency within an action. 


An action may contain any number of subactions, some of which may be performed sequentially, some 


‘Lampson, B. W., "Atomic Traneactions", in Distributed Systems—Architecture and implementation, Lecture Notes in Computer 
Science, volume 105, pages 246-265. Springer-Verlag, New York, 1981. 


?Gray, J. N., "Notes on data base operating systems”, in Operating Systems, An Advanced Course, Bayer, R.., Graham, Ri. M., 
and Seegmufier, G. (editors), Lecture Notes in Computer Science, volume 60, pages 303-481. Springer-Verlag, New York, 1978. 
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concurrently. This structure cannot be observed from outside the action; the overall action is still atomic. 
Subactions appear as atomic actions with respect to other subactions of the same parent. Thus, 
subactions can be executed concurrently. 


Subactions can commit and abort independently, and a subaction can abort without forcing its parent 
action to abort. However, the commit of a subaction is conditional: even if a subaction commits, aborting 
its parent action will abort it. 


The root of a tree of nested actions is called a topaction. Topactions have no paremt; they cannot be 
aborted once they have committed. Since the effects of a subaction can always be undone by aborting 
its parent, the two-phase commit protocol! is used onty when topactions attempt to commit. 


In Argus, an action (e.g., a handler cail) may return objects through either a normal return or an 
exception and then abort. The following rule shouki be followed to avoid violating serializability: a 
subaction that aborts should not retum any information obtained from data shared with other concurrent 
actions. 


2.2.2. Atomic Objects and Atomic Types 

Atomicity of actions is achieved via the data objects shared among those actions. Shared objects must 
be implemented so that actions using them appear to be atomic. Objects that support atomicity are 
referred to as atomic objects. Atomic objects provide the synchronization and recovery needed to ensure 
that actions are atomic. An atomic type ie a type whose objects are ail atomic. Some objects do not need 
to be atomic: for example, objects that are local to a single process. Since the synchronization and 
recovery needed to ensure atomicity may be expensive, we do not require that all types be atomic. (For 
example, Argus provides ali the built-in mutable types of CLU; these types are not atomic.) However, it is 
important to remember that atomic actions must share only atomic objects. 


Argus provides a number of built-in atomic types and type generators. The built-in scalar types (null, 
node, bool, char, Int, real, and string) are atomic. Parameterized types can also be atomic. Typically, 
an instance of a type generator will be atomic only if any actual type parameters are also atomic. The 
built-in immutable type generators (sequence, struct, and oneof) are atomic if their parameter types are 
atomic. In addition, Argus provides three mutable atomic type generators: atomic__ array, 
atomic_record, and atomic_variant. The operations on these types are nearly identical to the normal 
array, record, and variant types of CLU. Users may also define thelr own atomic types (see Section 15). 


The implementation of the built-in mutable atomic type generators is based on a simple locking model. 
There are two kinds of locks: read locks and write locks. When an action calls an operation on an atomic 
object, the implementation acquires a lock on that object In the appropriate mode: it acquires a write lock 
if it mutates the object, or a read lock if it only examines the object. The built-in types allow multiple 
concurrent readers, but only a single writer. If necessary, an action ie forced to wait until t can obtain the 
appropriate lock. When a write lock on an object is first obtained by an action, the system makes a copy 
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of the object's state in a new version, and the operations called by the action work on this version®. If, 
ultimately, the action commits, this version will be retained, and the old version discarded. A subaction’s 
locks are given to ts parent action when it commits. When a topaction commits, its locks are discarded 
and its effects become visible to other actions. if the action aborts, the action’s locks and the new version 
will be discarded, and the old version retained (see Figure 2-1). 


Figure 2-1: Locking and Version Management Rules for a Subaction S, on Object X 


Acquiring a read lock: 
All holders of write locks on X must be ancestors of S. 


Acquiring a write lock: 
All holders of read and write locks on X must be ancestors of S. 
Hf this is the first time S has acquired a write lock on X, 
push a copy of Xon the top of ts version stack. 


Commit: 
S's parent acquires S's lock on X. 
if S holds a write lock on X, then S's version becomes S's parent's version. 


Abort: 
S's lock and version (if any) are discarded. 


More precisely, an action can obtain a read lock on an object if every action holding a write lock on that 
object is an ancestor of the requesting action. An action can obtain a write lock on an object if every 
action holding a (read or write) lock on that object is an ancestor. When a subaction commits, its locks 
are inherited by its parent and its new versions replace those of ts parent; when a subaction aborts, its 
locks and versions are discarded (see Figure 2-1). Because Argus guarantees that parent actions never 
run concurrently with their children, these rules ensure that concurrent actions never hold write locks on 
the same object simuRaneously. 


The ancestors of a subaction are itself, its parent, its parent’s parent, and so on; a subaction is a 
descendant of its ancestors. A subaction commits to the fop it it and all ts ancestors, including the 
topaction, commit. A subaction is a committed descendant of an ancestor action i the subaction and ail 
intervening ancestors have committed. When a topaction attempts to commit, the two-phase commit 
protocol is used to ensure that the new versions of all objects modified by the action and ail its committed 
descendants are copied to stable storage. After the new versions have been recorded stably, the oid 
versions are thrown away. 


User-defined atomic types can provide greater concurrency than built-in atomic types‘. An 


*Thie operational description (and others in this manual) is not meant to constrain impiementors. However, this particular 
description does reflect our current implementation. 


“An example can be found in Weihi, W. and Liskov, B., "Implementation of Resilient, Atomic Data Types,” ACM Transactions on 
Programming Languages and Systeme, volume 7, number 2 (April 1965), pages 244-269. 
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implementation of a user-defined atomic type must address several issues. First, # must provide proper 
synchronization so that concurrent calls of its operations do not interfere with each other, and so that the 
actions that call Its operations are serialized. Second, it must provide recovery for actions using its 
objects so that aborted actions have no effect. Finally, t must ensure that changes made to its objects by 
actions that commit to the top are recorded properly on stable storage. The built-in atomic types and the 
mutex type generator are useful in coping with these issues. User-defined atomic types are discussed 
further in Section 15. 


2.2.3. Nested Topactions 

In addition to nesting subactions inside other actions, it is sometimes useful to start a new topaction 
inside another action. Such a nested topaction, unlike a subaction, has no special privileges relative to its 
“parent”; for example, it is not able to read an atomic object modified by its “parent”. Furthermore, the 
commit of a nested topaction is not relative to its “parent”; its versions are written to stable storage, and 
its locks are released, just as for normal topactions. 


Nested topactions are useful for benevolent side effects that change the representation of an object 
without affecting its abstract state. For example, in a naming system a name look-up may cause 
information to be copied from one location to another, to speed up subsequent look-ups of that name. 
Copying the data within a nested topaction that commits ensures that the changes remain in effect even if 
the “parent” action aborts. 


A nested topaction is used correctly if t is serializable before its “parent”. This is true # either the 
nested topaction performs a benevolent side effect, or if all communication between the nested topaction 
and its parert is through atomic objects. 


2.3. Remote Calls 

An action running in one guardian can cause work to be performed at another guardian by calling a 
handler provided by the latter guardian. An action can cause a new guardian to be created by calling a 
creator. Handler and creator calls are remote calls. Remote calle are similar to local procedure caiis; for 
example, the calling process waits for the call to return. Remote calls differ from local procedure calls in 
several ways, however. 


First, the arguments and results of a remote call are passed by value (see below and also Section 14) 
rather than by sharing. This ensures that the local objects of one guardian remain local to that guardian, 
even if their values are used as arguments or results of remote calls to other guardians. The only objects 
that are passed by sharing in remote calls are the global objects: guardians, handlers, creators, and 
nodes. 


Second, any remote call can raise the exceptions failure and unavailable. (Uniike CLU, not ail local 
Calls can raise failure, see Appendix IV.) The occurrence of failure means that the call ie unlikely to ever 
succeed, so there is no point in retrying the call in the future. Unevadable, on the other hand, means that 
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the call should succeed if retried in the future, but is unlikely to succeed if retried immediately. For 
example, failure can arise because it is impossible to transmit the arguments or results of the call (see 
Section 14); unavailable can arise if the guardian being called has crashed, or # the network is 
partitioned. 


Third, a handier or creator can be called only from inside an action, and the cail runs as a subaction of 
the calling action. This ensures that a remote call succeeds af most once: either a remote call completes 
successfully and commits, or it aborts and ail of ts modifications are undone (provided, of course, that the 
actions involved are truly atomic). Although the effect of a remote call occurs at most once, the sysiem 
may need to attempt it several times; this is why remote calls are made within actions. 


2.4. Transmissible Types 

Arguments and results of remote calls are passed by value. This means that the argument and result 
objects must be copied to produce distinct objects. Not all objects can be copied like this; those that can 
are called transmissible objects, and their types are called tranemiesible types. Only transmissbie 
objects may be used as arguments and results of a remote call. In addition, image objects (see Section 
6.6) can contain only transmissible objects. Parameterized types may be transmissible in some instances 
and not in others; for example, instantiations of the built-in type generators are tranemissibie only if their 
parameter types are transmissible. While guardians, creators, and handlers are always transmissibie, 
procedures and iterators are never transmissible. 


Users can define new transmissible types. For each transmissible type 7 the external representation 
type of T must be defined; this describes the format in which objects of type 7 are transmitted. Each 
cluster that implements a transmissible type 7 must contain two procedures, encode and decode, to 
translate objects of type 7 to and from their external representation. More information about defining 
transmissible types can be found in Section 14. 


2.5. Orphans 

An orphan is an action that has had some ancestor "perish" or has had the pertinent results of some 
relative action lost in a crash. Orphans can arise in Argus due to crashes and explicit aborts. For 
example, when a parent action is aborted, the active descendents k leaves behind become orphans. 
Crashes also cause orphans: when a guardian crashes, ail active actions with an ancestor at the crashed 
guardian and all active actions with committed descendants that ran at the crashed guardian become 
orphans®. However, having a descendent that is an orphan does not necessarily imply that the parent is 
an orphan; as previously described, actions may commit or abort independently of their subactions. 


Argus programmers can largely ignore orphans. Argus guarantees that orphans are aborted before 


5Walker, E. F., "Orphan Detection in the Argus System", Massachusetts Institute of Technology, Laboratory for Computer 
Science, Technical Report MIT/LCS/TR-326, June 1964. ! 
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3. Environment 
The Argus environment ensures complete static type checking of programs. It also supports separate 
compilation and the independence of guardians. 


3.1. The Library 

Argus modules are compiled in the context of a library that gives meaning to extemal identifiers and 
allows inter-module type checking. The Argus library contains type information about abstractions; for 
each abstraction, the Hbrary contains a description unit, or DU, describing that abstraction and its 
implementations. Each DU has a unique name and these names form the basis of type checking. 


3.2. Independence of Guardian Images 

The code run by a guardian comes from some guardian image. A guardian image contains all the code 
needed to carry out any local activity of the guardian; any procedure, Kerator or cluster used by that 
guardian will be in ts guardian Image. Any handler calls made by the guardian, however, are carried out 
at the called guardian, which contains the code that performs the call. Thus a guardian is independent of 
the implementations of the guardians kK calls and the implementation of a guardian can be changed 
without affecting the implementations of its clients. 


3.3. Guardian Creation 

When a guardian is created, it is necessary to select the guardian image that will supply the code run 
by the new guardian. To this end, each guardian has an associated creation environment that specifies 
the guardian images for other guardians t may create. The creation environmen is a mapping from 
guardian types to information that can be used to select a guartian image appropriate for each kind of 
node. For greater flexibility, this information can be associated with particular creator objects. 


3.4. The Catalog 

Somehow, guardians must be able to find other guardians to call for services. A guardian usually has a 
reference to any guardian k creates. Also, if a guardian can call some other server guardian, t can learn 
about the guardians that the server "knows", because guartiians can be passed in remote caiis. In 
addition, Argus provides a built-in subsystem known by ail guardians. This subsystem is called the 
catalog. The catalog provides an atomic mapping from names to transmissible objects. For example, 
when a new guardian is created, it can be catalogued under some well-known name, so that other 
guardians can find it in the future. Since we are currently experimenting with various interfaces to the 
catalog, we do not include an interface specification here. 
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4. Notation 
We use an extended BNF grammar to define the syntax of Argus. The general form of a production is: 
nonterminal :.= altemative 


| alternative 
| alternative 
The following extensions are used: 
@ , wee a list of one or more a’s separated by commas: “a” or "a, a" or "a, a, a” etc. 
{a} a sequence of zero or more a’s: "" or "a" or “a a” etc. 
[a] an optional a: "" or "a". 


Nonterminal symbols appear in normal face. Reserved words appear in bold face. All other terminal 
symbols are non-aiphabetic, and appear in normal face. 


Full productions are not always shown in the body of this manual; often alternatives are presented and 
explained individually. Appendix | contains the complete syntax. 
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5. Lexical Considerations 

A module is written as a sequence of tokens and separators. A token is a sequence of "printing" ASCII 
characters (values 40 octal through 176 octal) representing a reserved word, an identifier, a literal, an 
operator, or a punctuation symbol. A separator is a "blank" character (space, vertical tab, horizontal tab, 
carriage return, newline, form feed) or a comment. Any number of separators may appear between 
tokens. 


5.1. Reserved Words 
The following character sequences are reserved word tokens: 


Table 5-1: Reserved Words 


abort else leave signals 
action elseif mutex stable 
any end nil string 
array erter node struct 
atomic_array equates null tag 
atomic_record except oneof tagcase 
atomic_variant exk others tagtest 
background false own tagwait 
begin for pause terminate 
bind foreach proc then 
bool fork process topaction 
break guardian proctype transmit 
cand handier real true 
char handiertype record type 
cluster handles recover up 
coenter has rep variant 
continue if resignal when 
cor image return where 
creator in returns while 
creatortype int seize with 

evt is sel wiag 
do iter sequence yield 
down itertype signal yleids 


Upper and lower case letters are not distinguished in reserved words. For example, ‘end’, END’, and 
‘eNd’ are all the same reserved word. Reserved words appear in bold face in this document. 


5.2. Identifiers 
An identifier is a sequence of letters, digits, and underscores (_) that begins with a letter or underscore, 
and that is not a reserved word. Upper and lower case letters are not distinguished in identifiers. 


In the syntax there are two different nonterminals for identifiers. The nonterminail in is used when the 
identifier has scope (see Section 7.1); idns are used for variables, parameters, module names, and as 
abbreviations for constants. The nonterminal name is used when the identifier is not subject to scope 
rules; names are used for record and structure selectors, oneof and variant tags, operation names, and 
exceptional condition names. — 
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5.3. Literals 
There are literais for naming objects of the built-in types null, bool, Int, real, char, and string. Their 
forms are described in Appendix |. 


5.4. Operators and Punctuation Tokens 
The following character sequences are used as operators and punctuation tokens. 


Table 5-2: Operator and Punctuation Tokens 


( [ ~ 7 < ~< = 

) ] $ = I <= ~em ms 
{ = i + >a ~>= & 
} : @ / - > ~> | 


5.5. Comments and Other Separators 
A comment is a sequence of characters that begins with a percent sign (%), ends with a newline 
character, and contains only printing ASCII characters (including blanks) and horizontal tabs in between. 
For example: 
Zz = afi] + % a comment in an expression 


bi] 


A separator is a blank character (space, vertical tab, horizontal tab, carriage return, newline, form feed) 
or a comment. Zero or more separators may appear between any two tokens, except that at least one 
separator is required between any two adjacent non-self-terminating tokens: reserved words, identifiers, 
integer literals, and real literals. This rule is necessary to avoid lexical ambiguities. 
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6. Types, Type Generators, and Type Specifications 

A type consists of a set of objects together with a set of operations used to manipulate the objects. 
Types can be classified according to whether their objects are mutable or immutable, and atomic or 
non-atomic. An immutable object (e.g., an integer) has a value that never varies, while the value (state) 
of a mutable object can vary over time. Objects of atomic types provide serializability and recovery for 
accessing actions. Non-atomic types may provide synchronization by specifying that particular operations 
are executed indivisibly on objects of the type. An operation is indivisible if no other process may affect or 
observe intermediate states of the operation's execution. indivisibilty properties will be described for all 
the built-in non-atomic types of Argus. 


A type generator is a parameterized type definition, representing a (usually infinite) set of related types. 
A particular type is obtained from a type generator by writing the generator name along with specific 
values for the parameters; for every distinct set of legal values, a distinct type is obtained (see Section 
12.6). For example, the array type generator has a single parameter that determines the element type; 
array(int], array{real], and arrayfarray(int]] are three distinct types defined by the array type generator. 
Types obtained from type generators are called parameterized types or instantiations of the type 
generator; others are called simple types. 


In Argus code, a type is specified by a syntactic construct called a type_spec. The type specification 
for a simple type is just the identifier (or reserved word) naming the type. For parameterized types, the 
type specification consists of the identifier (or reserved word) naming the type generator, together with the 
actual parameter values. 


To be used as arguments or results of handier and creator calls, or as Image objects (see Section 6.6), 
objects must be transmissible. Most of the built-in Angus typee are transmissible, that is, they have 
transmissible objects. However, procedures and iterators are never transmissible. For type generators, 
transmissibility of a particular instantiation of the generator may depend upon transmissibility of any type 
parameters. A transmissible type provides the peeudo-operation tranemik and two intemal operations 
encode and decode. Generally, encode and decode are hidden from clients of the type. They are called 
implicitly during message transmission (see Section 14) and in creating and decomposing image objects 
(see Section 6.6). Transmissibility is discussed further In Section 14. 


Argus provides ali the built-in types of CLU as well as some new types and type generators. This 
section gives an informal introduction to the built-in types and type generators provided by Argus. Many 
details are not discussed here, but a complete definition of each type and type generator is given in 
Appendix Il. 
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The binary operations add (+), sub (-), mul (*), div ()), mod (/), power (°*), max, and min are provided, as_. 
well as unary minus (-) and abs. There are binary comparison operations /t(<), le (<=), equal (=), 
ge (>=), and gt(>). There are two operations, from_to and from_io_by, for kerating over a range of 
integers. See Section II.4 for details. 


6.2.4. Real 

The type real models (a subset of) the mathematical real numbers. The exact subset is not part of the 
language definition. Reals are immutable, atomic, and transmigsibie, although transmission of real 
objects between heterogeneous machine architectures may not be exact. Real iterals are written as a 
mantissa with an optional exponent. A mantissa is either a sequence of one or more decimal digits, or 
two sequences (one of which may be empty) joined by a period. The mantissa must contain at least one 
digit. An exponent is 'E’ or ‘e’, optionally followed by ‘+’ or '-’, followed by one or more decimal digits. An 
exponent is required if the mantissa does not contain a period. As is usual, MEx = n*'10*%. Examples of 
real literals are: 

3.14 3.14E0 3146-2 .0314E+2 3. 14 


As with integers, the operations add (+), sub(-), mul(*), div(), mod(//), power(**), max, min, 
minus (-), abe, it (<), le (<=), equal (=), ge (>=), and gt (>), are provided. It is important to note that there 
ts no form of implicit conversion between types. The r operation converts an integer to a real, 12/ rounds 
a real to an integer, and irunc truncates a real to an integer. See Section 11.5 tor details. 


6.2.5. Char 

The type char provides the alphabet for text manipulation. Characters are immutable, atomic, 
transmissible, and form an ordered set. Every implementation must provide at least 128, but no more 
than 512, characters; the first 128 characters are the ASCII characters in their standard order. 


Literals for the printing ASCII characters (octal 40 through octal 176), other than single quote (’) or 
backslash (\), can be written as that character enclosed in single quotes. Any character can be written by 
enclosing one of the escape sequences listed in Table 6-1 in single quotes. The escape sequences may 
be written using upper case letters, but note that escape sequences of the form \&" are case sensitive. A 
table of literals is given at the end of Appendix |. Examples of character Merals are: 

\7 ‘a’ a7 x" a \B’ \177' 


There are two operations, i2c and c2i, for converting between integers and characters: the smallest 
character corresponds to zero, and the characters are numbered sequentially. Binary comparison 
operations exist for characters based on this numerical ordering: it (<), fe (<=), equal (=), ge (>=), and 
gt(>). For details, see Section I!.6. 
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the mutability and atomicity of an any object depend on the mutability and atomicity of the contained 
object. Objects of type any are not transmissible. 


The create operation is parameterized by a type; creaie takes a single argument of that type and 
returns an any object containing the argument. The force operation is also parameterized by a type; it 
takes an any and extracts an object of that type, signalling wrong _fype if the contained object's type is 
not included in the parameter type. The is_type operation is parameterized by a type and checks whether 
its argument contains an object whose type is included in the parameter type. The detailed specification 
is found in Section 11.19. 


6.2.8. Sequence Types 
Sequences are immutable and they are atomic or transmissible when instantiated with atomic or 
transmissible type parameters. Although an individual sequence can have any length, the length and 
members of a sequence are fixed when the sequence is created. The elements of a sequence are 
indexed sequentially, starting from one. A sequence type specification has the form: 
sequence [ type_actual ] 
where a type_actual is a type_spec, possibly augmented with operation bindings (see Section 12.6). 


The new operation returns an empty sequence. A sequence constructor has the form: 


type_spec $[[ expression, ...]] 
and can be used to create a sequence with the given eiements. 


Although a sequence, once created, cannot be changed, new sequences can be constructed from 
existing ones. by means of the addh, adal, remh, and rem/ operations. Other operations include fetch, 
replace, top, bottom, size, the elements and indexes iterators, and subseq. invocations of the fetch 
operation can be written using a special form: 

qi] % fetch the element at indexiofq . 


Two sequences with equal elements are equal. The equa/(=) operation tests if two sequences have 
equal elements, using the equal operation of the element type. Simiar tests if two sequences have 
similar elements, using the similar operation of the element type. 


All operations are indivisible except for fll_ copy, equal, similar, copy, encode, and decode, which are 
divisible at calls to the operations of the type parameter. 


For the detailed specification, see Section II.8. 


6.2.9. Array Types 

Arrays are one-dimensional, and mutable but not atomic. They are transmissible only if their type 
parameter is transmissible. The number of elements in an array can vary dynamically. There is no notion 
of an “uninitialized” element. 


= Types, Type Gonmmtere, and Type Specifications 


The state of on areay coraitn ef an tetager cated the for hou, ate a: seqeonee of cbfactn cated the 


array { type_actual | 


Thar ar nero ye et & nw ey, i ony tw ry sone hr. The create 


cxvayiind $ (5: 1, 2, 3, 4) 
creates an integer aray willl: new bourne 5, end jour elomenta, whe 
creates a boolean array wilh low bound 1 (the dafeull}, end ten stements. 


An aray type speciation sates suting ave he tease an rey. Vanceenennanntie 


All operations are indivisible, cap cay, cr, hart, apy, smote nd decode, wich 
Cieitie at calle to eperttions of the type pecemeter. 


6.2.10, Structure Types oe . 
eharemtgubapesrnpagasnsmcmbehmesiiiie ss: Sabie. An insteniiaiion is atonic o 


sarvot {fahd_spec. ay 
whore 
fletd_spec <2 name , ... : ype_ectual 
Selectors must be unkyee wihin « epedilionion, bat the ox 


6.2.10 Structure Types 27 


A structure is created using a structure constructor. For example, assuming that “info” has been 
equated to a structure type: 
info = structilast, first, middie: string, age: Int] 
the following is a legal structure constructor: 
info $ {last: "Scheifier", first: "Robert", age:32, middie: "W."} 
An expression must be given for each selector, but the order and grouping of selectors need not 
resemble the corresponding type specification. 


For each selector "sel", there is an operation get_se/ to extract the named component, and an 
operation replace_sel to create a new structure with the named component replaced with some other 
object. Invocations of the get operations can be written using a special form: 

st.age % get the ’age’ component of st 


As with sequences, two structures with equal components are in fact the same object. The equal (=) 
operation tests if two structures have equal components, using the equa/ operations of the component 
types. Similar tests if two structures have similar components, using the similar operations of the 
component types. 


All operations are indivisible except for equal, similar, copy, encode, and decode, which are divisible at 
calls to the operations of the type parameter. 


For the detailed specification, see Section Ii.11. 


6.2.11. Record Types 
A record is a mutable collection of one or more named objects. Records are never atomic, and are 
transmissible only if the parameter types are all transmissible. A record type specification has the form: 
record [ field_spec, ...] 
where (as for structures) 
field_spec :°= name , ... : type_actual 
Selectors must be unique within a specification, but the ordering and grouping of selectors is unimportant. 


A record is created using a record constructor. For example: 
professor §$ {last: "Herlihy"; first: "Maurice", age:32, middie: "P."} 


For each selector “sel”, there is an operation get__se/ to extract the named component, and an 
operation set__se/ to replace the named component with some other object. invocations of these 
operations can be written using a special form: 


r.middie % get the ‘middie’ component of r 
rage :=33  % set the ‘age’ component of r to 33 (by calling set_age) 


As with arrays, every newly created record has an identity that is distinct from all other records; two 
records can have the same components without being the same record object. The identity of records 
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can be distinguished with the equal (=) operation. The simiar! operation tests if two records have equal 
components, using the equa/ operations of the component types. Similartests If two records have similar 
components, using the similar operations of the component types. 


All operations are indivisible, except similar, similar!, copy, encode, and decode, which are divisible at 
calls to operations of the type parameters. 


For the detailed specification, see Section 11.12. 


6.2.12. Oneof Types 
A oneof type is a tagged, discriminated union. A oneof is an immutable labeled object, to be thought of 

as “one of" a set of akematives. The label is called the tag, and the object is called the va/ue. A oneof 
type specification has the form: 

oneof | field_spec, ... ] 
where (as for structures) 

tield_spec ..= name , ... : type_actual 
Tags must be unique within a specification, but the ordering and grouping of tags is unimportant. An 
instantiation is atomic or transmissible if and only if all the type parameters are atomic or transmissible. 


For each tag “t" of a oneof type, there is a make_t operation which takes an object of the type 
associated with the tag, and returns the object (as a oneof) labeled with tag “t”. 


To determine the tag and value of a oneof object, one normally uses the tagcase statement (see 
Section 10.14). 


The equal (=) operation tests f two oneofs have the same tag, and # so, tests if the two value 
components are equal, using the equa/ operation of the value type. Sinilar tests if two oneofs have the 
same tag, and if so, tests if the two value components are similar, using the similar operation of the value 
type. 


All operations are indivisible, except equal, similar, similar!, copy, encode, and decode, which are 
divisible at calls to operations of the type parameters. 


For the detailed specification, see Section 11.14. 


6.2.13. Variant Types 
A variam is a mutable oneof. Variants are never atomic and are transmissible if and only if their type 
parameters are ail transmissible. A variant type specification has the form: 
variant [ field_spec , ... ] 
where (as for oneofs) 


field_spec ::= name , ... : type_actual 
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The state of a variant is a pair consisting of a label called the tag and an object called the vaiue. For each 
tag "t" of a variant type, there is a make_t operation which takes an object of the type associated with the 
tag, and returns the object (as a variant) labeled with tag “t". In addition, there is a change_t operation, 
which takes an existing variart and an object of the type associated with “t", and changes the state of the 
variant to be the pair consisting of the tag ‘t" and the given object. To determine the tag and value of a 
variant object, one normally uses the tagcase statement (see Section 10.14). 


Every newly created variant has an identity that is distinct from ail other variants; two variants can have 
the same state without being the same variant object. The identity of variants can be distinguished using 
the equal (=) operation. The similar? operation tests if two variants have the same tag, and if so, tests if 
the two value components are equal, using the equa/ operation of the value type. Similar tests if two 
variants have the same tag, and if so, tests if the two value components are similar, using the similar 
operation of the value type. 


All operations are indivisible, except similar, similar!, copy, encode, and decode, which are divisible at 
Calls to operations of the type parameters. 


For the detailed specification, see Section I1.15. 


6.2.14. Procedure and Iterator Types 

Procedures and iterators are created by the Argus system or by the bind expression (see Section 9.8). 
They are not transmissible. As the identity of a procedure or erator is immutable, they can be 
considered to be atomic. However, their atomicity can be violated if a procedure or iterator has own data 
and thus a mutable state. The immutability and atomicity of a procedure or Kerator with own data 
depends on that operation's specified semantics. 


The type specification for a procedure or iterator contains most of the information stated in a procedure 
or iterator heading; a procedure type specification has the form: 


proctype ( [ type_spec,, ... ] ) [ returns ] [ signals ] 
and an iterator type specification has the form: 


hertype ( [ type_spec , ... ] ) [ yields ] [ signats ] 


where 
returns sem Feturns ( type_spec, ...) 
yields 22 ylelds ( type_spec, ... ) 
signals :-= signals ( exception , ... ) 


exception 2: name [ ( type_spec, ...) ] 
The first list of type specifications describes the number, types, and order of arguments. The returns or 
yleids clause gives the number, types, and order of the objects to be returned or yielded. The signals 
clause lists the exceptions raised by the|procedure or Kerator; for each exception name, the number, 
types, and order of the objects to be returned is also given. All names used in a signais clause must be 
unique. The ordering of exceptions is not important. 
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Procedure and Iterator types have an equa/(=) operation. Invocation is not an operation, but a 
primitive in Argus. For the detailed specification of proctype and Kertype, see Section I!.17. 


6.3. Atomic_Array, Atomic_Record, and Atomic_Variant 

Having described the types that Argus inherited from CLU, we now describe the new types in Argus. 
The mutable atomic type generators of Argus are atomic_array, atomic _record, and atomic_variant. 
Types obtained from these generators provide the same operations as the analogous types obtained from 
array, record, and variant, but they differ in their synchronization and recovery properties. Conversion 
operations are provided between each atomic type generator and ks non-atomic partner (for example, 
atomic_array[t}$aaZa converts from an atomic array to a (non-atomic) array). 


An operation of an atomic type generator can be classified as a reader or writer depending on whether 
it examines or modifies its principal argumem, that is, the argument or resuR object of the operation’s 
type. (For binary operations, such as ar_ gets ar, the operation is classified with respect to each 
argument.) Intuitively, a reader only examines (reads) the state of its principal argument, while a writer 
modifies (writes) its principal argument. Operations that create objects of an atomic type are classified as 
readers. Reader/writer exclusion is achieved by locking: readers acquire a read lock while writers 
acquire a write lock. The locking rules are discussed in Section 2.2.2. 


If one or more of the type parameters is non-atomic, then the resulting type is not atomic because 
modifications to component objects are not controlied. However, read/write locking still occurs, as 
described above. Thus, an atomic type generator instantiated with a non-atomic parameter incurs the 
expense of atomic types without gaining any benefit; such an instantiation is unlikely to be a correct 
solution to a problem. Atomic type generators yield transmissible types only if the type parameters are ail 
transmissible. 


Special operations are provided for each atomic type generator to test and manipulate the locks 
associated with reader/writer exclusion. These operations are useful for implementing user-defined 
atomic types (see Section 15). The tagtest and tagwak statements (see Section 10.15) provide 
additional structured support for atomic_variants. The operations can_read, can_write, Test_and_read, 
and test_and_write provide relatively unstructured access to lock information. For complete definitions of 
these operations, see Sections 11.10, 11.13, and 11.16. 


Assuming normal termination, the following operations acquire read locks on their principal arguments 
or the objects that they create. 


atomic_array: create, new, predict, fill, fill_copy, size, low, high, empty, top, bottom, fetch, similar, 
similar!, copy, copy!, elements, indexes, test__and__read, a2aa, aa2a, encode, 
decode 


atomic_record: create, get_ , similar, similar!, copy, copy1, test_and_read, ar_gets__ar (second 
argument), rar, ar2r, encode, decode 


atomic_variant: make_, is_, value_, av_gets_av (second argument), similar, similar!, copy, copy!, 
lest_and_read, v2av, av2v, encode, decode 
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The operations similar and similar! acquire read locks on both arguments. The operations copy and 
copy? acquire a read lock on the value retumed as well as their principal argument. Test_and_read is a 
reader only if it returns true; otherwise it is nether a reader nor a writer. 


Assuming normal termination, the following operations acquire write locks on their principal arguments. 
atomic_array: Set_low, trim, store, addh, addi, remh, reml, test_and_write 
atomic_record: set_, ar_gets_ar (first argument), fest_and_write 
atomic_variant: change_, av_geis_av (first argument), test_and_write 

Test_and_write is a writer only if it returns true; otherwise it is neither a reader nor a writer. 


The equal, can_read, and can_write operations are neither readers nor writers. 


When an operation of atomic_ array terminates with an exception, ts principal argument is never 
moditied; however, the atomic_: operations listed above as writers always obtain a write lock before 
the principal argument is examined, hence there are cases in which they will obtain a write lock and only 
read, but not modify their principal argument. For example, atomic_arrayft}$i7im is a writer when it 
signals bounds. On the other hand, when an atomic_ array operation raises a signal because of an 
invalid argument, no locks are obtained. For example, when atomic_array[t}]$iim signals negative_size, 
it is neither a reader nor a writer since the array’s state is neither examined nor modified (only the integer 
argument is examined). 


For the detailed specification of atomic arrays, see Section 11.10; for atomic records, see Section 1.13; 
and for atomic variants, see Section I!.16. 


6.4. Guardian Types 

Guardian types are user-defined types that are implemented by guardian definitions (see Section 13). 
A guardian definition has a header of the form: 

idn = guardian [ parms] is idn, ... [handles idn, ... ] [ where ] 

The creators are the operations named in the identifier list following Is; a creator is a special kind of 
operation that can be called to create new guardians that behave in accordance with the guardian 
definition. Each guardian optionally provides handiers that can be called to interact with it; the names of 
these handlers are listed in the identifier list following handies. (See Section 13 for more details.) 


A guardian definition named g defines a guardian interface type g. An object of the guardian interface 
type provides an interface to a guardian that behaves in accordance with the guardian definition. An 
interface object is created whenever a new guardian is created, and then the interface object can be used 
to access the guardian's handlers. Interface objects are transmissible, and after transmission they still 
give access to the same guardian. In this manual a “guardian interface object” ie often called simply a 
“guardian object". 


The guardian type g for the guardian definition named g has the following operations. 
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1. The creators listed in the Is list of the guardian definition. 


2. For each handler name h listed in the handies list, an operation get__h with type: 
proctype (9) returns (4), where ht is the type of /. 


3. Equal and similar, both of type: proctype (g, g) returns (bool), which return true only if 
both arguments are the same guardian object. 


4. Copy, of type: proctype (9) returns (9), which simply returns ts argument. 
5. transmit. 
Accreator may not be named equal, similar, copy, print, or get_h where his the name of a handler. 


Thus if x is a variable denoting a guardian interface object of type g, and fh is a handler of g, then 
Gget_h(x) will return this handler. As usual with get_ operations, this call can be abbreviated to x.h. 
Note that the handlers themselves are not operations of the guardian interface type; thus o$h would be 
illegal. 


A guardian interface type is somewhat like a structure type. Its objects are constructed by the creators, 
and decomposed by the get_operations. Guardian interface objects are immutable and atomic. 


6.5. Handler and Creator Types 
Creators are operations of guardian types. Handler objects are created as a side-effect of guardian 
creation. Unlike procedures and Kerators, handiers and creators are transmissible. 


The types of handlers and creators resemble the types of procedures: 


handiertype ( [ type_spec, ...] ) [ retums ] [ signats } 
creatortype ( [ type_spec, ... ] ) [ returns ] [ signais ] 


The argument, normal result, and exception resuk types must all be tranemissible. The signals list for a 
handiertype or creatortype cannot include either fa#ure or unavailable, as these signais are implicit in 
the interface of all creators and handiers. 


Handler and creator types provide equa/ and similar operations which return true if and only # both 
arguments are the same object, and copy operations which simply retum their argument. For the detailed 
specification of handiertype and creatortype, see Section 11.18. 


6.6. Image 

The image type provides an escape from compile-time type checking. The main difference between 
Image and any is that Image objects are transmissible. An image object can be thought of as a portion 
of an undecoded message or as the information needed to recreate an object of some type. Image 
objects are immutable and atomic. 


The create operation is parameterized by a transmissible type; Kt takes a single argument of that type 
and encodes it (using the encode operation of that type) into an Image object. The force operation is also 
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parameterized by a transmissible type; it takes an image object and decodes it (using the decode 
operation of that type) to an object of that type, signalling wrong_type if the encoded object's type is not 
included in the parameter type. The is_type operation is parameterized by a type and checks whether its 
argument is an encoded object of a type included in the parameter type. See Section 11.20 for the 
detailed specification. 


6.7. Mutex 

Mutex objects are mutable containers for information. They are not atomic, but they provide 
synchronization and control of writing to stable storage for their contained object. Mutex Kself does not 
provide operations for synchronizing the use of mutex objects. instead, mutual exclusion is achieved 
using the seize statement (see Section 10.16), which allows a sequence of statements to be executed 
while a process is in exclusive possession of the mutex object. Mutex objects are transmissibie if the 
contained object is transmissible. 


The type generator mutex has a single parameter that is the type of the contained object. A mutex 
type specification has the form: 
mutex [type_actual] 
Mutex types provide operations to create and decompose mutex objects, and to notify the system of 
modifications to the mutex object or its contained object. 


The create operation takes a single argument of the parameter type and creates a new mutex object 
containing the argument object. The get_ value operation obtains the contained object from its mutex 
argumem, while set_va/ue modifies a mutex object by replacing its contained object. As with records, 
these operations can be called using special forme, for example: 


m: mutex{int] := mutex{int}$create (0) 
x: Int := m.value % extract the contained object 
m.value := 33 % change the contained object 


Set_vaiue and get_value are indivisible. 


Mutexes can be distinguished with the equa/ (=) operation. There are no operations that could cause 
or detect sharing of the contained object by two mutexes. Such sharing is dangerous, since two 
processes would not be synchronized with each other in their use of the contained object # each 
possessed a different mutex. In general, if an object is contained in a mutex object, # should not be 
contained in any other object, nor should it be referred to by a variable except when in a seize statement 
that has possession of the containing mutex. 


There are some mutex operations that seize the mutex object automatically. Copy seizes its single 
argument object. Similar seizes its two argument objects; the first argument object is seized first and then 
the second. In both cases possession is retained until the operations return. Also, when a mutex object 
is encoded (for a message or when making an image), the object is seized automatically. See Section 
11.21 for the detailed specification of mutex. 
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Mutexes are used primarily to provide process synchronization and mutual exclusion on shared data, 
especially to implement user-defined atomic types. In such implementations, it is important to control 
writing to stable storage. The mutex operation changed provides the necessary control. Changed 
informs the system that the calling action requires that the argument object be copied to stable storage 
before the commit of the action’s top-level parent (topaction). Any mutex is asynchronous: its contained 
object is written to stable storage independently of objects that contain that mutex. See Section 15 for 
further discussion of user-defined atomic objects. 


6.8. Node 
Objects of type node stand for physical nodes. The operation here takes no arguments and retums 
the node object that denotes its caller's node. Equal, similar, and copy operations are also provided. 


The main use of node objects is in guardian creation (see Section 13), where they are used to cause a 
newly created guardian to reside at a particular node. Objects of type node are immutable, atomic, and 
transmissible. For the detailed specification, see Section I1.2. 


6.9. Other Type Specifications 
A type specification for a user-defined type has the form of a reference: 
reference ..= 

| idn [ actual_parm, ... ] 

| reterence $ name 
where each actual parm must be a compile-time computable constant (see Section 7.2) or a type_acwa/ 
(see Section 12.6). A reference must denote a data abstraction to be used as a type specification; this 
syntax is provided for referring to a data abetraction that is named in an equate module (see Section 
12.4). For type generators, actual parameters of the appropriate types and number must be supplied. 
The order of parameters is always significant for user-defined types (see Section 12.5). 


There are two special type specifications that are used when implementing new abstractions: rep, and 
cvt. These forms may only be used within a cluster; they are discussed fusther in Section 12.3. 


Within an implementation of an abstraction, formal parameters deciared with type can be used as type 
specifications. Finally, identifiers that have been equated to type specifications can aiso be used as type 
specifications. 
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7. Scopes, Declarations, and Equates 

This section describes how to introduce and use constants and variables, and the scope of constant 
and variable names. Scoping units are described first, followed by a discussion of variables, and finally 
constants. 


7.1. Scoping Units 
Scoping units follow the nesting structure of statements. Generally, a scoping unit is a body and an 
associated “heading”. The scoping units are as follows (see Appendix | for details of the syntax). 
1. From the start of a moduie to its end. 
2. From a cluster, proc, Ker, equates, guardian, handler, or creator to the matching end. 


3. From a for, do, begin, background, recover, enter, coenter, or seize to the matching 
end. 


4. From a then or eise in an If statement to the end of the corresponding body. 


5. From a tag, wtag, or others in a tagcase, tagwalt, or tagtest statement to the end of the 
corresponding body. 


6. From a when or others in an except statement to the end of the corresponding body. 
7. From the start of a type_sef to its end. 
8. From an action or topaction to the end of the corresponding body. 


The structure of scoping units is such that if one scoping unit overlaps another scoping unit (textually), 
then one is fully contained in the other. The contained scope Is called a nested scope, and the containing 
scope is called a surrounding scope. 


New constant and variable names may be introduced in a scoping unit. Names for constants are 
introduced by equates, which are syntactically restricted to appear grouped together at or near the 
beginning of scoping units (except in type sets). For example, equates may appear at the beginning of a 
body, but not after any statements in the body. 


In contrast, declarations, which introduce new variables, are allowed wherever statements are allowed, 
and hence may appear throughout a scoping unit. Equates and declarations are discussed in more detail 
in the following two sections. 


In the syntax there are two distinct nonterminals for identifiers: idn and name. Any identifier introduced 
by an equate or deciaration is an idn, as is the name of the module being defined, and any operations it 
has. An jdn names a specific type or object. The other kind of identifier is a name. A name is generally 
used to refer to a piece of something, and is always used in context; for example, names are used as 
record selectors. The scope rules apply only to jdns. 


The scope rules are simple: 
1. An idn may not be redefined in its scope. 


2. Any idn that is used as an extemal reference in a module may not be used for any other 
purpose in that module. 


36 Scopes, Deciarations, and Equates 


Unlike other “block-structured™ languages, Argus prohibits the redefinition of an identifier in a nested 
scope. An identifier used as an external reference names a module or conetant; the reference is resolved 
using the compilation environment. 


7.1.1. Variables 

Objects are the fundamental "things" in the Argus universe; variables are a mechanism for denoting 
(i.¢., naming) objects. A variable has three properties: ks type, whether it is stable or not, and the object 
that it currently denotes (if any). A variable is said to be uninitialized f R does not denote any object. 
Attempts to use uninitialized variables are programming errors and (if not detected at compile-time) cause 
the guardian to crash. 


There are only three things that can be done with variables: 


1. New variables can be introduced. Declarations perform this function, and are described 
below. 


2. An object may be assigned to a variable. After an assignment the variable denotes the 
object assigned. 


3. A variable may be used as an expression. The value of a variable is the object that the 
variable denotes at the time the expression is evaluated. 


7.1.2. Declarations 
Declarations introduce new variables. The scope of a variable is from is deciaration to the end of the 
smallest scoping unit containing its declaration; hence, variables must be deciared before they are used. 


There are two sorts of deciarations: those with initialization, and those without. Simple declarations 
(those without initialization) take the form 
dec! 22= Idn, as. : type_spec 
A simple declaration introduces a list of variables, all having the type given by the type_spec. This type 
determines the types of objects that can be assigned to the variable. The variables introduced in a simple 
declaration initially denote no objects, i.e., they are uninitialized. 


A declaration with initialization combines declarations and assignments into a single statement. A 
declaration with initialization is entirely equivalent to one or more simple declarations followed by an 
assignment statement. The two forms of declaration with Intialization are: 

idn : type_ spec := expression 
and 

dec!,, «», decl, := call [ @ primary ] 
These are equivalent to (respectively): 


idn : type_ spec 
idn := expression 
and 
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deci, ...decl, % declaring idn, ... idn,, 

idn,, wee, idn,, = call [@ primary ] 
In the second form, the order of the idns in the assignment statement is the same as in the original 
deciaration with initialization. (The call must return m objects.) 


7.2. Equates and Constants 

An equate allows an identifier to be used as an abbreviation for a constant, type set, or equate module 
name that may have a lengthy textual representation. An equate also permits a mnemonic identifier to be 
used in place of a frequently used constant, such as a numerical value. We use the term constant in a 
very narrow sense here: constants, in addition to being immutable, must be computable at compile-time. 
Constants are either types (built-in or user-defined), or objects that are the results of evaluating constant 
expressions. (Constant expressions are defined below.) 


The syntax of equates is: 


equate ::= idn = constant 


| idn = type_set 
| idn = reference 


constant .3= type_spec 
| expression 


type_set ::= { idn | idn has oper_dect, ... { equate }} 


reference ..= idn 
| idn [ actual_parm,, «+ ] 
| reference $ name 
References can be used to name equate modules. 


An equated identifier may not be used on the left-hand side of an assignment statement. 


The scope of an equated identifier is the smallest scoping unit surrounding the equate defining ik; here 
we mean the entire scoping unit, not just the portion after the equate. Ail the equates in a scoping unit 
must appear grouped near the beginning of the scoping unk. The exact placement of equates depends 
on the containing syntactic construct; usually equates appear at the beginnings of bodies. 


Equates may be in any order within the a scoping unt. Forward references among equates in the 
same scoping unit are allowed, but cyclic dependencies are itega!. For example, 
Xmy 
y=z 
z=3 


is a legal sequence of equates, but 
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Xay 
y=zZ 
zZ=uX 


is not. Since equates introduce idns, the scoping restrictions on ides apply (Le., the idns may not be 
defined more than once). 


7.2.1. Abbreviations for Types | 
identifiers may be equated to type specifications, giving shibrevigtions for ype names. 


7.2.2. Constant Expressions 

We define the aubsst ef chjects thet equated identifiers may dencte by siafing which expressions are 
constant expressions. (Exprecaion: we decussat in detell i Seaton #.) A qonatent expesesion 6 an 
pang of « bult-in type. This 


expression that can be evaluated at compile-time to produes at # 
inchides: 
1. Literals. 


2. identifiers equated to constants. 

3. Formal parameters. 

4. Procedure, Rerator, and creator names. 

5. Sr expen (oe Satan 8. wharf rae baud ane ep pert ae 


The bult-n invutabhe ‘pen are: mult, tt, sunt, tek, eh $ING. seence types, oneal pes, 
structure types, procedure types, ilerator types, and creator Qpes. . 


Oe ee ee on ee eres Sennen Oo Slee ee ree cereenen ee 
area ef & constant expression 
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8. Assignment and Calls 
The two fundamental activities of Argus programs are calls and assignment of computed objects to 
variables. 


Argus programs should use mutual exclusion or atomic data to synchronize access to ail shared 
variables, because Argus supports concurrency and thus processes can interfere with each other during 
assignments. For example, 

i:=1 

ji=2 
is not equivalent to 

i,j:=1,2 
in the presence of concurrent assignments to the same variables, because any interleaving of indivisible 
events is possible in the presence of concurrency. 


Argus is designed to allow complete compile-time type-checking. The type of each variable is known 
by the compiler. Furthermore, the type of objects that could resutt from the evaluation of any expression 
is known at compile time. Hence, every assignmem can be checked at compile time to ensure that the 
variable is only assigned objects of its declared type. An assignment v := E is legal only # the type of Eis 
included the type of v. The definition of type inclusion is given in Section 6.1. 


8.1. Assignment 

Assignment causes a variable to denote an object. Some assignments are implicitly performed as part 
of the execution of various mechanisms of the language (in exception handiing, and the tagcase, tagtest, 
and tagwakt statements). All assignments, whether implicit or explicit, are subject to the type inclusion 
rule. 


8.1.1. Simple Assignment 
The simplest form of assignment statement is: 
idn := expression 

In this case the expression is evaluated, and then the resulting object is assigned to the variable named 
by the idn in an indivisible event. Thus no other process may observe a "half-assigned" state of the 
variable, but another process may observe various states during the expression evaluation and between 
the evaluation of the expression and the assignment. The expression must return a single object (whose 
type must be included in that of the variable). 


8.1.2. Multiple Assignment 
There are two forms of assignment statement that assign to more than one variable at once: 
iN , eas := EXPression , oe. 
and 
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idn , ««. := call [ @ primary ] 


The first form of multiple assignment is a generalization of simple assignment. The first variable is 
assigned the first expression, the second variable the second expression, and so on. The expressions 
are all evaluated (from left to right) before any assignments are performed. The assignment of multiple 
objects to multiple variables is an indivisible event, but evaluation of the expressions is divisible from the 
actual assignment. The number of variables in the list must equal the number of expressions, no variable 
may occur more than once, and the type of each variable must include the type of the corresponding 
expression. 


The second form of multiple assignment allows one to retain the objects resulting from a call returning 
two or more objects. The first variable is assigned the first object, the second variable the second object, 
and so on, but all the assignments are carried out indivisibly. The order of the objects is the same as in 
the return statement executed in the called routine. The number of variables must equal the number of 
objects returned, no variable may occur more than once, and the type of each variable must include the 
corresponding retum type of the called procedure. 


8.2. Local Calls 
In this section we discuss procedure calls; iterator calls are discussed in Section 10.12. However, 
argument passing is the same for both procedures and iterators. 


Local calls take the form: 
primary ( [ expression , ... J ) 


The sequence of activities in performing a local call are as follows: 
1. The primary is evaluated. 
2. The expressions are evaluated, from left to right. 


3. New variables are introduced corresponding to the formal arguments of the routine being 
called (i.¢e., a new environment is created for the called routine to execute in). 


4. The objects resulting from evaluating the expressions (the actual arguments) are assigned 
to the corresponding new variables (the formal arguments). The first formal is assigned the 
first actual, the second formal the second actual, and so on. The type of each expression 
must be included in the type of the corresponding formal argument. 


5. Control is transferred to the routine at the start of its body. 
A call is considered legal in exactly those situations where all the (implick) assignments are legal. 


A routine may assign an object to a formal argument variable; the effect is just as # that object were 
assigned to any other variable. From the point of view of the called routine, the only diiference between 
its formal argument variables and its other local variables is that the formats are initialized by its caller. 


Procedures can terminate in two ways: they can terminate normally, returning zero or more objects, or 
they can terminate exceptionally, signalling an exceptional condition. When a procedure terminates 
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normally, any result objects become available to the caller, and can be assigned to variables or passed as 
arguments to other routines. When a procedure terminates exceptionally, the flow of control will not go to 
the point of retum of the call, but rather will go to an exception handler (see Section 11). 


8.3. Handler Calis 

As explained in Section 2 and in Section 13, a hander is an operation that belongs to some guardian. 
A handier call causes an activation of the called handler to run at the handier's guardian; the activation is 
performed at the called handier’s guardian by a new subaction created solely for this purpose. Usually 
the handlers guardian is not the same as the one in which the cail occurs, and the called handler's 
guardian is likely to reside at a different node in the network than the calling guardian. However, it is legal 
to call a handler that belongs to a guardian residing at the caller's node, or even to call a handler 
belonging to the caller's guardian. 


Although the form of a handler cail looks like a procedure call: 


primary ( { expression, ... ] ) 
its meaning is very different. Among other things, a handier is called remotely, with the arguments and 
results being transmitted by value in messages, and the call is run as a subaction of its calling action. 
Below we present an overview of what happens when executing a handler call and then a detailed 
description. 


A handler call runs as a subaction of the calling action. We will refer to this subaction as the cai action. 
The first thing done by the cail action is the transmission of the arguments of the call. Transmission is 
accomplished by encoding each argument object, using the encode operation of its type. The arguments 
are decoded at the called guardian by a subaction of the call action called the activation action. Each 
argument is decoded by using the decode operation of its type. The effect of transmission is that the 
arguments are passed by value from the caller to the handier activation: new objects come into existence 
at the handier’s guardian that are copies of the argument objects. Object values are transmitted in such a 
way as to preserve the intemal sharing structure of each argument object is preserved®, as well as any 
sharing structure between the argument objects in a single call. See Section 14 for further discussion of 
transmission. 


After the arguments have been transmitted, the activation action performs the handler body. When the 
handler body terminates, by executing a return, abort return, signal, or abort signal statement, the 
result objects are transmitted to the caller by encoding them at the handier's guardian, and committing or 
aborting the activation action (as it specified). The call action then decodes the results at the caller's 
guardian. Once the results have been transmitted to the caller, the call action commits and execution 
continues in the caller as indicated by the caller's code. (Note that the call action will commit even if the 
activation action aborts.) 


*This is only strictly true for the built-in types. A user-defined type might not preserve intemal sharing structure. 
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8.3.1. Semantics of Handler Calls 
In this section we describe the semantics of a handler call in detail. A handler call causes activity at 
both the calling guardian and at the called guardian. At the calling guardian, the sequence of activities in 
pertorming a handier call ie as follows: 
1. The primary is evaluated. 
2. The argumem expressions are evaluated from left to right. 


3. A subaction, which we will refer to as the cal action, is created for the remote call. 
subsequent activity on behalf of the call will be performed by the call action or one 
descendants. For it to be poesibie to create the call action, the 
running as an action. Remote calis by non-actions are programming errors and cause the 


calling guardian to crash. 

4. A call message is constructed. As part of constructing this message, encode operations 
are performed on the argumert 4 any of the encode operations terminates with a 
failure exception, then the remote call will terminate with the same exception, and the call 
action will be aborted. 

5. The call message is sent to the guardian of the called handler, and the call action waits for 
the completion of the cail. 


6. If the call message arrives at the node of the target guardian, and the target guardian does 
not exist, then the call action is aborted with the faidure exception having the string 
“guardian does not exist" as ks exception result. , 


7. If the system determines that k cannot communicate with the called guardian, # aborts the 


cause this kind of termination only when it is extremely unlikely that retrying the call 
immediately will succeed. 


8. Ordinarily, a call completes when a reply message containing the results is received. When 
the reply message arrives at the caller, It ie decoded using the decode operation for each 
result object. if any decode terminates with a failure exception, the call action is aborted, 
and the call terminates with the same exception. Otherwise, the call action commits. 


9. The Call will terminate normaily i the result message indicates that the handler activation 
returned (instead of signalied); otherwise it terminates with whatever exception was 
signalled. 


At the called guardian, the following activities take place. 


1. A subaction of the call action is created at the target guardian to run the call. We will refer 
to this subaction as the activation action. Ali activity at the target guardian occurs on behatf 
of the activation action or one of its descendants. 


see clei pent agers cyte inn plop rhe As part of this process 
decode on each argument. if any decode terminates with a 
falkr6 estacioh. heh tis scialion acta aoted. and the call terminates with the same 
exception. 


3. The called handier is called within the activation action. This cali is ike a reguiar procedure 
call. The objects obtained from decoding the message are the actual arguments, and they 
are bound to the formais via implicit assignments. 


4. If the handler terminates by executing an abort return or an abort signal statement (see 
Section 11.1), then all committed descendents of the activation action are aborted. Then 
the reply message is constructed by encoding the result objects, the activation action is 
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aborted, and the reply message is sent to the caller. Otherwise, when the handier 
terminates, the reply message is constructed by encoding the result objects, the activation 
action commits, and the reply message is sent.to the caller. If one of the callie of encode 
terminates with a failure exception, then the activation action is aborted, and the call 
terminates with the same exception. 


When the Argus system terminates a call with the unavadable exception, it is possible that the 
activation action and/or some of its descendants are actually running. This could happen, for exampie, if 
the network partitions. These running processes are called “orphans”. The Argus system makes sure 
that orphans will be aborted before they can view inconsistent data (see Section 2.5). 


8.4. Creator Calls 

Creators are called to cause new guardians to come into existence. As part of the call, the node at 
which the newly created guardian will be located may be specitied. if the node is not specified, then the 
new guardian is created at the same node as the caller of the creator. The form of a creator call is: 


primary ( [ expression, ... ] ) [ @ primary ] 
The primary following the at-sign (@) must be of type node. 


A creator call causes two activities to take place. First, a new guardian is created at the indicated 
node. Second, the creator is called as a handler at the newly created guardian. This handler cali has 
basically the same semantics as the reguiar handler call described above. 


The Argus system may also cause a creator call to abort with the fa#ure or unavailable exceptions. 
The reasons for such terminations are the same as those for handler calls, and the meanings are the 
same: the failure exception means that the call should not be retried, while the unavailable exception 
means that the call should not be retried immediately. 


8.4.1. Semantics of Creator Calls 


The activities carried out in executing a creator call are as follows. 
1. The (first) primary is evaluated. 


2. The argument expressions are evaluated from left to right. 


3. The optional primary following the at-sign is evaluated to obtain a node object. If this 
Primary is missing, the node at which the call is taking place is used. 


4. A subaction, which we will refer to as the call action, ie created. All subsequent activity 
takes place within this subaction. As was the case for handler calls, creators can be called 
only from within actions. A creator call by @ non-action is a programming error and causes 
the calling guardian to crash. 


5. A new guardian is created at the indicated node. The creator obtained in step 1 will indicate 
the type of this guardian. The selection of a particular load image for this type will occur as 
discussed in Section 3.3. 


6. As was the case for handier calis, # the system cannot communicate with the indicated 
node, the creator call will terminate with the unavailable exception. if the system is unable 
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to determine what implementation to load, or i#f there is no implementation of the type that 
can run on the indicated node, or # the manager of the node refuses to allow the new 
guardian to be created, the creator call will terminate with the fafure exception. In either 
case the call action will be aborted. 


7.A remote call is now performed to the creator. This call has the same semantics as 
described for handier calls above in steps 4 through 9 of the activities at the calling node 
and also steps 1 through 4 of activities at the called node. However, if either the call action 
or the activation action aborts, the newly created guardian will be destroyed. 


For example, suppose we execute the creator call 
x: G = G$create(3) @ n 
where Gis a guardian type, n denotes an object of type node, and create has header 
create = creator (n: Int) returns (G) signals (not_possibie(string)) 
The system will select an implementation of G that is suitable for use at node n, and will then create a 
guardian at node rn running that Implementation. Next create (3) is performed as a handler call at that 
new guardian. If create retums, then the assignment to x will cocur, causing x to refer to the new 
guardian that creaie retumed; now we can call the handlers provided by G. The exceptions that can be 
signalled by this call are not_possib/e, failure, and unavailable. An example of a cail that handies all 
these exceptions Is: 
x: G «= G$create (3) @ n 
except when not_possible (s: string): ... 


when failure (s: string): ... 
pg unavailable (s: string): ... 


Creators are described in more detail in Section 13. 


46 


9 Expressions 47 


9. Expressions 

An expression evaluates to an object in the Argus universe. This object is said to be the result or value 
of the expression. Expressions are used to name the object to which they evaluate. The simplest forms 
of expressions are Iterals, variables, parameters, equated identifiers, equate module references, 
procedure, iterator, and creator names, and self. These forms directly name their result object. More 
complex expressions are buik up out of nested procedure calis. The result of such an expression is the 
value returned by the outermost call. 


9.1. Literals 

Integer, real, character, string, boolean and null literals are expressions. The type of a literal 
expression is the type of the object named by the literal. For example, true is of type bool, “abc” is of 
type string, etc. (see the end of Appendix | for details). 


9.2. Variables 

Variables are identifiers that denote objects of a given type. The type of a variable is the type given in 
the declaration of that variable. An attempt to use an uninitialized variable as an expression is a 
programming error and causes the guardian to crash. 


9.3. Parameters 

Parameters are identifiers that denote constants supplied when a parameterized module Is instantiated 
(see Section 12.5). The type of a parameter is the type given in the declaration of that parameter. Type 
parameters cannot be used as expressions. 


9.4. Equated Identifiers 
Equated identifiers denote constants. The type of an equated identifier is the type of the constant 


which it denotes. identifiers equated to types, type__ sets, and equate modules cannot be used as 
expressions. 


9.5. Equate Module References 
Equate modules provide a named set of equates (see Section 12.4). To use a name defined in an 
equate module as an expression, one writes: 
reference $ name 
where 
reference 22 
| idn [ actual_parm, ... ] 
| reference $ name 
The type of a reference is the type of the constant which Kk denotes. ‘identifiers equated to types, 
type_sets, and equate modules cannot be used as expressions. 
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The evaluation of a bind expression proceeds by first evaluating the entity and then evaluating, from 
left to right, any bind_args that are expressions. The entity may evaluate to a procedure, iterator, 
handier, or creator object. Suppose that the entity is a procedure or Kerator object. (Creator and handier 
bindings are discussed below.) Then the resuk is formed by binding the argument objects to the 
corresponding formals of the entity to form a closure; note that the procedure or iterator is not called when 
the bind expression is evaluated. When the closure is called, the object denoted by the entity is passed 
all the bound objects and any actual arguments supplied in the call, all in the corresponding argument 
positions. 


For example, suppose we have: 
p = proc(x: T, y: Int, w: S) returne(R) signals(too_big) 
Then 
q := bind p(", 3 + 4, *) 
produces a procedure whose type is proctype(7, S) returns(A) signals(foo_big) and assigns tt to q. A 
call of g(a, b) is then equivalent to the call p(a, 7, b). 


Bound routines will be stored in stable storage # they are accessible from a stable variable (see 
Section 13.1). In this case the entity and the bind_args should denote atomic objects. 


There is only one instance of a routine’s own data for each parameterization; thus ail the bindings of a 
routine share its own data, f any (see Section 12.7). Each binding is generality a new object; thus the 
relevant equal operation may treat syntactically identical bindings as distinct. 


The semantics of binding a creator or handler are similar to binding a procedure or iterator; the 
differences arise from argument transmission. Encoding of bound argument objects happens when the 
bind expression is evaluated and sharing is only preserved among objects bound at the same time (see 
Section 14). In more detail, the evaluation of a bind expression proceeds by first evaluating the entity 
and then evaluating, from left to right, any bind_args that are expressions. Then the argument objects 
are encoded, from left to right, preserving sharing among these objects. The result is formed by binding 
the encoded argument objects to the corresponding formals of the entity to form a closure. Note that the 
entity is not called when the bind expression is evaluated. 


When the closure is called, first any other arguments are evaluated and encoded (not sharing with the 
bound objects) and then the call to the entity is initiated. Decoding of the arguments at the called 
guardian is done in reverse of the order of encoding; that is, other arguments are decoded before bound 
arguments and the most recently bound arguments are decoded first. Sharing is preserved on decoding 
only among groups of bound arguments and among the other arguments, not between groups. 
Thereafter the call proceeds as normality. 


For example, if we execute 


h1 := bind h(x, y, *) 
h1(z) 
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then sharing of objects between x and y will be preserved by transmission, but sharing will not be 
preserved between x and z or y and z. 


Closures can be used in equates, provided all the expressions are constants (see Section 7.2.2). 
However, a handler cannot appear in an equate, since & is not a constant. 


9.9. Procedure Calis 
Procedure calls have the form: 


primary ( [ expression , ... ] ) 
The primary is evaluated to obtain a procedure object, and then the expressions are evaluated left to right 
to obtain the argument objects. The procedure is called with these arguments, and the object returned is 
the result of the entire expression. For more discussion see Section 8. 


Any procedure call p(E,, ... E,,) must satisfy two constraints to be used as an expression: the type of p 
must be of the form: 
proctype (T,, ..., T,,) returns (R) signais (...) 
and the type of each expression & must be included in the corresponding type 7. The type of the entire 
call expression is given by R. 


9.10. Handler Calls 
Handier calls have the form: 


primary ( [ expression, ... ] ) 
The primary is evaluated to obtain a handler object, and then the expressions are evaluated left to right to 
obtain the argument objects. The handler is then called with these arguments as discussed in Section 
8.3. The following expressions are examples of handier calls: 

h(x) 

info_guard.who_is_user("john", "doe") 

dow_jones.info("XYZ Corporation”) 

Any handler call A(E,, ... E,,) must satisfy the following constraints when used as an expression. The 

type of / must be of the form: 

handiertype (T,, ... T,) returns (R) signais (...) 
and the type of each expression £, must be included in the corresponding type 7; The type of the entire 
call expression is given by A. 


As explained in Section 8.3, the execution of a handler cail starts by creating a subaction. Therefore 
an attempt to call a handler from a process that is not running an action is a programming error and will 


cause the calling guardian to crash. This crash occurs after all of the component expressions have been 
evaluated. 
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9.11. Creator Calls 
Creator calls have the form: 


primary ( [ expression, .«. ]) [ @ primary ] 
The first primary is evaluated to obtain a creator object, the argument expressions are evaluated left to 
right to obtain the argument objects, and then the primary following the at-sign (@), if present, is 
evaluated to obtain a node object. If the primary following the at-sign is omitted, then node$hera() is 
used. The guardian is then created at that node, and the creator called, as discussed in Section 8.4. The 
following are examples of creator cails: 

mailer$create() @ n 

spooler{devtype}$create() 


A creator call c/E,,,...,E,)@n must satisfy the following constraints when used as an expression. The 
type of c must be of the form: 
creatortype (T,,...,7,,) returns (R) signals (...) 
where each 7; includes the type of the corresponding expression &. N must be of type node. The type 
of the entire call expression Is given by A. 


As with handler calls, an attempt to call a creator from a process that is not running an action will cause 
the calling guardian to crash after all component expreasions have been evaluated. 


9.12. Selection Operations 

Selection operations provide access to the individual elements or components of a collection. Simple 
notations are provided for calling the fetch operations of array-tke types, and the get operations of record- 
like types. In addition, these "syntactic sugarings” for selection operations may be used for user-defined 
types with the appropriate properties. 


9.12.1. Element Selection 
An elemem selection expression has the form: 
primary [ expression ] 
This form is just syntactic sugar for a call of a fetch operation, and is computationally equivalent to: 
T$fetch(primary, expression) 
where T is the type of the primary. T must provide a procedure operation named fetch, which takes two 
arguments whose types include the types of primary and expression, and which returns a single result. 


9.12.2. Component Selection 
The component selection expression has the form: 
primary . name 
This form is just syntactic sugar for a call of a get_name operation, and is computationally equivalent to: 
T$get_name(primary) 
where T is the type of primary. T must provide a procedure operation named get_name, that takes one 
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argument and returns a single result. Of course, the type of the procedure’s argument must include the 
type of the primary. 


9.13. Constructors 
Constructors are expressions that enable users to create and initialize sequences, arrays, atomic 
arrays, structures, records, and atomic records. There are no constructors for user-defined types. 


9.13.1. Sequence Constructors 
A sequence constructor has the form: 


type_spec $ | [ expression , ... ] } 
The type_spec must name a sequence type: sequence{7]. This is the type of the constructed sequence. 
The expressions are evaluated to obtain the elements of the sequence. They correspond (left to right) to 
the indexes 1, 2, 3, etc. For a sequence of type sequence| 7], the type of each element expression in the 
constructor must be included in T. 


A sequence constructor is computationally equivalent to a sequence new operation, followed by a 
number of sequence addh operations. 


9.13.2. Array and Atomic Array Constructors 
An array or atomic array constructor has the form: 


type_spec $[ [ expression : ] [ expression, ... ] } 

The type_spec must name an array or atomic array type: array[7] or atomic_array[7)]. This is the type of 
the constructed array. The optional expression preceding the colon (:) must evaluate to an integer, and 
becomes the low bound of the constructed array or atomic array. If this expression Is omitted, the low 
bound is 1. The optional list of expressions is evaluated to obtain the elements of the array. These 
expressions correspond (left to right) to the indexes jow_bound, low_bound+1, low_bound+2, etc. For an 
array or atomic array of type array[7] or atomic_array[7], the type of each element expression in the 
constructor must be included in 7. A constructor of the form array[T}${] has a low bound of 1 and no 
elements. 


An array constructor is computationally equivaient to a create operation, followed by a number of addh 
operations. 


9.13.3. Structure, Record, and Atomic Record Constructors 
A structure, record, or atomic record constructor has the form: 
type_spec $ { field, ...} 
where 
field :°= name , ... : expression 
Whenever a field has more than one name, it is equivalent to a sequence of fields, one for each name. 
Thus, if = record] a: Int, b: Int, c: Int J, then the following two constructors are equivalent: 
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R${a, b: p(t), ¢: 9} 
R${a: p(), b: pt), oc: 9} 


In the following we discuss only record constructors; structure and atomic record constructors are 
similar. In a record constructor, the type specification must name a record type: record[S,:7,, ..., S,:7,]- 
This is the type of the constructed record. The component names in the field list must be exactly the 
names S,, ..., S,, although these names may appear in any order. The expressions are evaluated left to 
right, and there is one evaluation per component name even i several component names are grouped 
with the same expression. The type of the expression for component S; must be included in T, The 
results of these evaluations form the components of a newly constructed record. This record is the value 
of the entire constructor expression. 


9.14. Prefix and Infix Operators 

Argus allows prefix and infix notation to be used as a shorthand for the operations listed in Table 9-1. 
The table shows the shorthand form and the computationally equivalent expanded form for each 
operation. For each operation, the type Tis the type of the first operand. 


Table 9-1: Prefix and Infix Operators: shorthands and expansions 


Shorthand form Expansion 
expr, ** expr. T$power(expr,, expr.) 
al Tsavienpr, opr) 

x 1 2 xp}, OxPr, 
Oxpr, . @XPI5 T$mul(expr,, expr) 
expr, ll @Xxpre T$ooncat(expr,, expr.) 
expr, + expr, T$add(expr,, expr.) 
expr, — expr, T$eub(expr,, expr.) 
expr, < expr, TSk(expr,, expr.) 
expr, <= expr, T$le(expr,, expr.) 
expr, = expr, T$equatexpr,, expr.) 
OXPr, >= OXPro T$ge(expr,, expr.) 
expr, > xpr, pas at 
expr, ~< OXpr = @xpr, < OXpr, 
—— inaee 
SAC = ONO NORD OKENS 
@xpr, ~>= expr, ~ (expr, >= expr.) 
expr, ~> expr, ~ (expr, > expr.) 
expr, & expr, T$and(expr,, expr.) 
expr, | expr, T$ortexpr,, expr) 

— expr T$minus(expr) 
~ expr T$not(expy 


Operator notation is used most heavily for the built-in types, but may be used for user-defined types as 
well. When these operations are provided for user-defined types, they should be free of side-effects, and 
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they should mean roughly the same thing as they do for the buik-in types. For example, the comparison 
operations should only be used for types that have a natural partial or total order. Usually, the 
comparison operations (/t, /e, equal, ge, gf) will be of type 

proctype (T, T) returns (boo!) 
the other binary operations (e.g., add, sub) will be of type 

proctype (T, T) returne (T) signals (...) 
and the unary operations will be of type 

proctype (T) returns (1) signals (...) 


9.15. Cand and Cor 
Two additional binary operators are provided. These are the conditional and operator, cand, and the 

conditional or operator, cor. The result of evaluating: 

expression, cand expression, 
is the boolean and of expression, and expression,. However, if expression, is false, expression, is 
never evaluated. The resul of evaluating: 

expression, cor expression, 
is the boolean or of expression, and expression,, but expression, is not evaluated unless expression, is 
false. For both cand and cor, expression, and expression, must have type bool. 


Because of the conditional expression evaluation involved, uses of cand and cor are not equivalent to 
any procedure call. 


9.16. Precedence 
When an expression is not fully parenthesized, the proper nesting of subexpressions might be 
ambiguous. The following precedence rules are used to resolve such ambiguity. The precedence of 
each infix operator is given in the table below. Higher precedence operations are performed first. Prefix 
operators always have precedence over infix operators. 
Table 9-2: Precedence for infix Operators 


Precedence Operators 

5 o* 

4 * 1 UW 

3 + - Il 

2 <= = >= > ~< ~<a ~= ~D>e ~> 
1 & cand 
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The order of evaluation for operators of the same precedence is left to right, except for **, which is right 
to left. 


9.17. Up and Down 
There are no implicit type conversions in Argus. Two forms of expression exist for explicit conversions. 
These are: 
up ( expression ) 
down ( expression ) 


Up and down may be used only within the body of a cluster operation (see Section 12.3). Up changes 
the type of the expression from the representation type of the cluster to the abstract type. Down converts 
the type of the expression from the abstract type to the representation type. 
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10. Statements 
ihahaprapasetencncedanghahialasnagpessies ox assstinsto ring the. 


the complete ayntax of statements. 


Atomic actions alow sequences of statements io sqpenr to be tnbalbe o other actions Sequences 


10.1. Calis 
A call statement may be used to call a procedure, handler, or oresior. For procedures and handlers its 
form is the same as a call expression: 
pronary { [ eupression , - }) 
The primary mutt be 8 precede, o handler stjeat. ‘em: pe of each actual expression must be 
inchided in the type of the dant 1g taenal enqumerd, The. puantue or handler may or may not 
return results; HR does reten results, they are dincartted. 


For creator calls the eyrtex is siniiary, tut one cate: 
to be created: . 
primary ( { expression , ...}){ @ pamay } 


The detalle of procedure, handler, and 
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10.2. Update Statements 

Two special statements are provided for updating components of record and array-like objects. In 
addition they may be used with user-defined types with the appropriate properties. These statements 
resemble assignments syntactically, but are actually cail statements. 


10.2.1. Element Update 
The element update statement has the form: 
primary [ expression, ] := expression, 
This form is merely syntactic sugar for a call of a store operation; it Is equivalent to the call statement: 
T$store(primary, expression,, expression,) 
where T is the type of the primary. T must provide a procedure named store that takes three arguments 
whose types include those of primary, expression,, and expression,, respectively. 


10.2.2. Component Update 
The component update statement has the form: 

primary . name := expression 
This form is syntactic sugar for a call of a set_ operation whose name is formed by attaching set_ to the 
name given. For example, if the name ie f, then the statement above is equivalent to the call statement: 

T$set_f(primary, expression) 
where T is the type of the primary. T must provide a procedure operation named set_f, where fis the 
name given in the component update statement. This procedure must take two arguments whose types 
include the types of primary and expression, respectively. 


10.3. Block Statement 
The block statement permits a sequence of statements to be grouped together into a single statement. 
Its form is: 
begin body end 
Since the syntax already permits bodies inside contro! statements, the main use of the block statement is 
to group statements together for use with the except statement (see Section 11). 


10.4. Fork Statement 
A fork statement creates an autonomous process. The fork statement has the form: 
fork primary ( [ expression, ... ] ) 
where the primary is a procedure object whose type has no results or signals (see Section 12.1). The 
type of each actual expression must be included in the type of the corresponding formal. 


Execution of the fork statement starts by evaluating the primary and actual argument expressions from 
left to right. Any exceptions raised by the evaluation of the primary or the expressions are raised by the 
fork statement. If no exceptions are raised, then a new process is created and execution resumes after 


10.4 Fork Statement 59 


the fork statement in the old process. The new process starts by calling the given procedure with the 
argument objects. This new process terminates i and when the procedure cali does. However, if the 
guardian crashes the process goes away (like any other process). 


Note that the new process does not run in an action, although the procedure called can start a 
topaction if desired. There is no mechanism for waiting for the termination of the new process. The 
procedure called in a fork statement cannot retum any results or signal any exceptions. 


10.5. Enter Statement 
Sequential actions are created by means of the enter statement, which has two forms: 

enter topaction body end 
and 

enter action body end 
The topaction qualifier causes the body to execute as a new top-level action. The action qualifier 
causes the body to execute as a subaction of the current action; an attempt to execute an enter action 
statement in a process that Is not executing an action is a programming error and causes the guardian to 
crash. When the body terminates, k does so either by committing or aborting. Normal compietion of the 
body results in the action committing. Statements that transfer control out of the enter statment (exit, 
leave, break, continue, return, signal, and resignal) normally commit the action unless are prefixed 
with abort (€.g., abort exit). Two-phase commit of a topaction may fail, in which case the enter 
topaction statement raises an unavailable exception. 


10.6. Coenter Statement 
Concurrent actions and processes are created by means of the coenter statement: 
coenter coarm { coarm } end 
where 


coarm ::= armtag [ foreach dec! , ... In call ] 
body 


armtag ::= action 
| topaction 
| process 


Execution of the coenter starts by creating all of the coarm processes, sequentially, in textual order. A 
foreach clause indicates that multiple instances of the coarm will be created. The cail in a foreach 
clause must be an iterator call. At each yield of the Rerator, a new coarm process is created and the 
objects yiekled are assigned to newly declared variables in that process. (This implict assignment must 
be legal, see Section 6.1.) Each coarm process has separate, local instances of the variables declared in 
the foreach clause. 
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The process executing the coenter is suspended until after the coenter Is finished. Once ail coarm 
processes are created, they are started simultaneously as concurrent siblings. Each coarm instance runs 
in a separate process, and each coarm with an armtag of topaction or action executes within a new 
top-level action or subaction, respectively. An attempt to execute a coenter with a process coarm when 
in an action, or to execute a coenter with an action coarm when not in an action is an error and will 
cause the guardian to crash (see Table 10-1). 


Table 10-1: Legality of coenter statements. 


process executing the coenter is: 
armtag not in an action running an action 
action not legal legal 
topaction legal legal 
process legal not legal 


A simple example making use of foreach is: 
coenter action foreach |: Int In Int$from_to (1, 5) 
P (i) 
end 
which creates five processes, each with a local variable /, having the value 1 in the first process, 2 in the 
second process, and so on. Each process runs in a newly created subaction. This statement is legal 


only if the process executing it is running an action. 


A coarm may terminate without terminating the entire coenter (and sibling coarms) either by normal 
completion of its body, or by executing a leave statement (see Section 10.7). The commit of a coarm 
deciared as a topaction may terminate in an unavailable exception if two-phase commit fails. Such an 
exception can only be handled outside the coenter statement, and thus will force termination of the entire 
coenter (as explained below). . 


A coarm may also terminate by transferring contro! outside the coenter statement. When such a 
transfer of control occurs, the following steps take place. 
1. Any containing statements are terminated divisibly, to the outermost level of the coarm, at 
which point the coarm becomes the controlling coarm. 


2. Once there is a controlling coarm, every other active coarm will be terminated (and abort if 
declared as an action) as soon as it leaves all selze statements; the controlling coarm is 
suspended until all other coarms terminate. 


3. The controlling coarm then commits or aborts if declared as an action; if declared as a 
topaction and the two-phase commit fails, an unavailable exception is raised by the coenter 
statement. 


4. Finally, the entire coenter terminates, and control flow continues outside the coenter 
statement. 


Divisible termination implies, for instance, that a nested topaction may commit while ks parent action 
aborts. 
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A simple example of early termination is reading from a replicated database, where any copy can 
supply the necessary information: 


coenter action foreach db: database in all_replicas (...) 
return( database$read (db)) 
end 


When one of these coarms completes first, it tries to commit tse and abort the others. The aborts take 
place immediately (since there are no seize statements); it is not necessary for the handier calls to finish. 
It is possible that some descendants of an aborted coarm may be running at remote sites when the coarm 
aborts; the Argus system ensures that such orphans will be aborted before they can make their presence 
known or detect that they are in fact orphans (see Section 2.5). 


10.7. Leave Statement 
The leave statement has the form: 
[ abort ] leave 
Executing a leave statement terminates the innermost enter statement or coenter coarm in which it 
appears. if the process terminated is an action, then it commits unless the abort qualifier is present, in 
which case the action aborts. The abort qualifier can only be used textually within an enter statement or 
within an action or topaction coarm of a coenter statemen. 


Note that unlike the other contro! flow statements, leave does not affect concurrent siblings in a 
coenter (see Section 10.6). 


10.8. Return Statement 
The form of the return statement is: 
[ abort ] return [ ( expression , ... ) ] 
The return statement terminates execution of the containing routine. If the return statement occurs in an 
erator no results can be returned. Hf the return statement is in a procedure, handler, or creator the type 
of each expression must be included In the correaponding return type of the routine. The expressions (if 
any) are evaluated from left to right, and the objects obtained become the results of the routine. 


ff no abort qualifier is present, then all containing actions (¥ any) terminated by this statement are 
committed. If the abort qualifier is present, then ail terminated actions are aborted. Note that unlike the 
leave statement, return will abort concurrent siblings if executed within a coarm of a coenter statement 
(see Section 10.6). The abort qualifier can only be used textually within an enter statement, an action or 
topaction coarm of a coenter statement, or the body of a handler or creator. 


Within a handler or creator, the result objects are encoded just before the activation action terminates, 
but after all control flow and nested action termination. If encoding of any result object terminates in a 
failure exception, then the activation action aborts and the handler or creator terminates with the same 
exception. 
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10.9. Yield Statement 
The form of a ylekd statement is: 

yield [ ( expression , ... ) ] 
The yield statement may occur only in the body of an iterator. The effect of a yleld statement is to 
suspend execution of the #erator invocation, and retum contro! to the calling for statement or foreach 
clause. The values obtained by evaluating the expressions (ieft to right) are passed back to the caller. 
The type of each expression must be included in the corresponding yield type of the iterator. Upon 
resumption, execution of the Kerator continues at the statement following the yleid statement. 


A yield statement cannot appear textually inside an enter, coenter, or seize statement. 


10.10. Conditional Statement 
The form of the conditional statement is: 
if expression then body 

{ elseif expression then body } 

[ etse body ] 

end 
The expressions must be of type bool. They are evaluated successively until one is found to be true. 
The body corresponding to the first true expression is executed, and the execution of the H statement 
then terminates. If there Is an elee clause and if none of the expreasione is true, then the body in the 
else clause is executed. 


10.11. While Statement 
The while statement has the form: 
while expression do body end 
Its effect is to repeatedly execute the body as long as the expression remains true. The expression must 
be of type bool. if the value of the expression Is true, the body is executed, and then the entire while 
statement is executed again. When the expression evaluates to faiee, execution of the wile statement 
terminates. 


10.12. For Statement 

An iterator (see Section 12.2) can be called by a for statement. The Kerator produces a sequence of 
items (where an item is a group of zero or more objects) one tem at a time; the body of the for statement 
is executed for each item in the sequence. 


The for statement has the form: 


for [ dec! , ... ] in call do body end 
or 


for [ idn, ... ] in call do body end 
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The call must be an iterator call. The second form (with an /dn list) uses distinct, previously declared 
variables to serve as the loop variables, while the first form (with a deci list) form introduces new 
variables, local to the for statement, for this purpose. In either case, the type of each variable must 
include the corresponding yield type of the called Kerator (see Section 12.2) and the number of variables 
must also match the yield type. 


Execution of the for statement begins by calling the Kerator, which either yields an tem or terminates. 
If it yields an item (by executing a yleld statement), its execution is temporarily suspended, the objects in 
the item are assigned to the loop variables, and the body of the for statement ie executed. The next 
cycie of the loop is begun by resuming execution of the Rerator after the yleld statement which 
suspended it. Whenever the iterator terminates, the entire for statement terminates. 


10.13. Break and Continue Statements 
The break statement has the form: 
[ abort ] break 
Its effect is to terminate execution of the smallest for or while loop statement in which it appears. 
Execution continues with the statement following that loop. 


The continue statement has the form: 
[ abort ] continue 
Its effect is to start the next cycle (if any) of the smallest for or while loop statement in which & appears. 


Terminating a cycle of a loop may also terminate one or more containing actions. Hf no abort qualifier 
Is present, then all these terminated actions (if any) are committed. if the abort qualifier is present, then 
all of the terminated actions are aborted. Unlike leave, break and continue will abort concurrent sibling 
actions when contro! flow leaves a containing coenter (see Section 10.6). 


The abort qualifier can only be used textually within an enter statement or an action or topaction 
coarm of a coenter statement. 


10.14. Tagcase Statement 

The tagcase statement can be used to decompose oneot and variant objects; atomic_variant objects 
can be decomposed with the tagtest or tagwalt statements. The decomposition is indivisible for variant 
objects; thus, use of the tagcase statement for variants is not equivalent to using a conditional statement 
in combination with is_ and value_ operations (see Section 11.15). . 


The form of the tagcase statement is: 
tagcase expression 
tag_arm { tag_arm } 
[ others : body ] 
end 
where 


64 Statements 


tag_arm ::= tag name, ... [ ( idn: type_spec ) ] : body 
The expression must evaluate to a oneof or variant object. The tag of this object is then matched 
against the names on the tag arms. When a match Is found, if a declaration (jon: type_ spec) exists, the 
value component of the object is assigned to the new local variable idn. The matching body is then 
executed; idn is defined only in that body. If no match is found, the body in the others arm is executed. 


In a syntactically correct tagcase statement, the following three constraints are satisfied. 
1. The type of the expression must be some oneof or variant type, 7. 


2. The tags named in the tag_arms must be a subset of the tags of 7, and no tag may occur 
more than once. 


3. If all tags of T are present, there is no others arm; otherwise an others arm must be 
present. 


On any tag__arm containing a declaration (idn: type_ spec), type_ spec must include the type(s) of T 
corresponding to the tag or tags named in that tag arm. 


10.15. Tagtest and Tagwait Statements 

The tagtest and tagwait statements are provided for decomposing atomic_variant objects, permitting 
the selection of a body based on the tag of the object to be made indivielbly with the testing or acquisition 
of specified locks. 


10.15.1. Tagtest Statement 
The form of the tagtest statement is: 
tagtest expression 
atag_arm { atag_arm } 
[ others : body ] 
end 
where , 
atag_arm ::= tag_kind name , ... [ ( idn: type_spec ) ] : body 
tag_kind ::= 
| wtag 
The expression must evaluate to an atomic_variant object. if a read lock could be obtained on the 
atomic_variant object by the current action, then the tag of the object is matched against the names on 
the alag_arms; otherwise the others arm, if present, is executed. if a matching name is found, then the 
tag_kind is considered. 
e if the fag_kind is tag, a read lock is obtained on the object and the match is complete. 


e If the fag_kind is wtag and the current action can obtain a write lock on the object, then a 
write lock is obtained and the match is complete. 


When a complete match is found, if a declaration (idn: type_ spec) exists, the value component of the 
object is assigned to the new local variable idn. The matching body is then executed; idn is defined only 
in that body. The entire matching process, including testing and acquisition of locks, is indivisible. 
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If a complete match is not found, or the object was not readable by the action, then the others arm (if 
any) is executed; ff there is no others arm, the tagteet statement terminates. if no complete match is 
found, then no locks are acquired. 


The tagtest statement will only obtain a lock if it is possible to do so without “waiting”. For example, 
suppose that the internal state of the atomic_ variant indicates that some previous action acquired a 
conflicting lock. This action may have since aborted, or may have committed up to an ancestor of the 
action executing the tagtest, but determining such facts may require system-level communication to other 
guardians. in this case the tagtest statement may give misleading information, because it may not 
indicate a match. Apparent anomalies in testing locks may occur even if the action executing the tagtest 
“knows” that the lock can be acquired, so that the use of tagtest to avoid deadiocks or long delays may 
result in excessive aborts. 


10.15.2. Tagwait Statement 
The form of the tagwalt statement is: 
tagwailt expression 

atag_arm { atag_arm } 

end 
Execution of the tagwalt statement proceeds as for the tagteet statement, but if no complete match is 
found, or if the object is not readable by the current action, then the entire matching process is repeated 
(after a system-controlied delay), until a complete match Is found. Although there is no others arm in a 
tagwait statement, all tag names do not have to be listed. 


10.15.3. Common Constraints 

Tagteet and tagwait statements may be executed only within an action. An attempt to execute a 
tagtest or tagwak statement in a process that is not executing an action is an error and will cause the 
guardian to crash after evaluating the expression. 


In a syntactically correct tagtest or tagwailt statement, the following three constraints are satisfied. 
1. The type of the expression must be some atomic_vartant type, T. 


2. The tags named in the aiag_arms must be a subset of the tags of T, and no tag may occur 
more than once. 


3. Finally, on any atag_arm comaining a declaration (idn: type_spec), type_ spec must include 
the type(s) specified as corresponding in 7 to the tag or tags named in the atag_arm. 


A simpie example of a tagtest statement is garbage collecting the elements of an array that are in the 
dequeued state: 


10.17. Pause Statement 
‘The pause statement tas the term: 


creatd be gvoided 
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10.18. Terminate Statement 
The terminate statement may occur only within a guardian definition (see Sect 13). The form of a 
terminate statement is: 
terminate 


When executed within an action, its effect is to cause the eventual destruction of the guardian after the 
enclosing action commits to the top. if a process attempts to execute terminate while not running an 
action, a topaction is created to execute the terminate and immediately cornmt. 


Let A be the action that is executing the términate. The effect of this statement is the following: 
1. Action A must wait until the action thet created the guardian ls committed relative to A. In 
the case of a permanent guardian whose creation has eoumeiited to the tap there will be no 
wait, but for a recently created guardian there may be a delay. 


2. If muRiple processes are attempting to execute terminate statements, at most one at at 
time may proceed to the next step. 


3. If A commits to the top, the guardian will be destroyed at some time after topaction commit. 


In order to avoid serialization problems, creation or destruction of a guardian must be synchronized 
with use of that guardian wa atomic objects auch as the catalog (see Section 3.4). 


68 


11 Exception Handling and Exits 69 


11. Exception Handling and Exits 

A routine is designed to perform a certain task. However, in some cases that task may be impossible 
to perform. In such a case, instead of retuming normally (which would imply successful performance of 
the intended task), the routine should notify its caller by signalling an exception, consisting of a descriptive 
name and zero or more result objects. 


The exception handling mechanism consists of two parts: signalling exceptions and handling 
exceptions. Signalling is the way a routine notifies its caller of an exceptional condition; handling is the 
way the caller responds to such notification. A signalled exception always goes to the immediate caller, 
and the exception must be handied in that caller. When a routine signals an exception, the current 
activation of that routine terminates and the corresponding call {in the caller) is said to raise the exception. 
When a call raises an exception, control immediately transfers to the closest applicable exception 
handler. Exception handlers are attached to statements; when execution of the exception handier 
completes, control passes to the statement following the one to which the exception handler is attached. 
For brevity, exception handlers will be called "handiers” in this chapter; these should not be confused with 
the remote call handiers of guardians (see Section 13). 


11.1. Signal Statement 
An exception is signalled with a signal statement, which has the form: 
[ abort ] signal name [ ( expression , ... ) ] 
A signal statement may appear anywhere in the body of a routine. The execution of a signal statement 
begins with evaluation of the expreesions (if any), from ieft to right, to produce a list of excapiion results. 
The activation of the routine is then terminated. Execution continues in the caller as described in Section 
11.2 below. 


The exception name must be one of the exception names listed in the routine heading. If the 
corresponding exception specification in the heading has the form: 
name(T,, as, T,) 
then there must be exactly n expressions in the signal statement, and the type of the /th expression must 
be included in 7. 


lf no abort qualifier is present, then all containing actions (if any) terminated by this statement are 
committed. If the abort qualifier is present, then all terminated actions are aborted. Unlike the leave 
statement, signal will terminate (abort) concurrem siblings # executed within a coenter siatement (see 
Section 10.6). The abort qualifier can only be used textually within an enter siatement, an action or 
topaction coarm of a coenter statement, or the body of a handler or creator. 


Within a handler or creator, the result objects are encoded just before the activation action terminates, 
but after termination of all control flow and nested actions. if encoding of any result object terminates in a 
failure exception, then the activation action aborts and the handler or creator terminates with the failure 
exception. 
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11.2. Except Statement 

When a routine activation terminates by signalling an exception, the called routine is said to raise that 
exception. By attaching exception handlers to statements, the caller can specify the action to be taken 
when an exception is raised by a call within a statement or by the statement itself. 


A statement with handlers attached is called an except statement, and has the form: 
statement except { when_handier } 
[ others_handier ] 
end 
where 
when_handler 3: when name , ... [ (dec! , ... ) ] : body 
| when name , ... (*) : body 


others_handler ::= others [ ( idn : string ) ] : body 
Let S be the statement to which the handlers are attached, and let X be the entire except statement. 
Each when_handier specifies one or more exception names and a body. The body is executed if an 
exception with one of those names is raised by a call in S. Each of the names listed in the 
when_handlers must be distinct. The optional others__handier is used to handie ail exceptions not 
explicitly named in the when_handiers. The statement S can be any form of statement, and can even be 
another except statement. As an example, consider the following except statement: 


m.send_maiuser, my_message) 
except when no_such_user: ... % body 1 
when unavailable, failure (s: string): ... % body 2 
when others (ename: string): ... % body 3 
end 


This statement handles exceptions arising from a remote call. If the call raises a no__such__user 
exception, then “body 1° will be executed. If the call raises a failure or unavailable exception, then "body 
2" will be executed. Any other exception will be handied by “body 3.” 


If, during the execution of S, some call in S raises an exception E, control transfers to the textually 
closest handler for E that is attached to a statement containing the call. When execution of the handler 
completes, control passes to the statement following the one to which the hander is attached. Thus if the 
closest handier is attached to S, the statement following X is executed next. If execution of S completes 
without raising an exception, the attached handlers are not executed. 


An exception raised inside a handier is treated the same as any other exception: control passes to the 
closest handler for that exception. Note that an exception raised in some handier attached to S cannot be 
handled by any handler attached to S; the exception can be handled within the handler, or i can be 
handled by some handler attached to a statement containing X. For example, in the following except 
statement: 
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times3_plus1(a) 
except when limits: 
ama+a 
when overflow: ... % body 2 
end 


any overfiow signal raised by the expression a + a will not be handied in “body 2,” because this overflow 
handler is not in an except statement attached to the assignment statement 2 := a + a. 


We now consider the forms of exception handlers in more detail. The form: 

when name , «.. [ (deci, ...) ] : body 
is used to handle exceptions with the given names when the exception results are of interest. The 
optional declared variables, which are local to the handler, are assigned the exception results before the 
body is executed. Every exception potentially handled by thie form must have the same number of results 
as there are deciared variables, and the types of the variables must include the types of the results. The 
form: 

when name , ... ( *) : body 
handles all exceptions with the given names, regardiess of whether or not there are exception results; any 
actual results are discarded. Using this form, exceptions with differing numbers and types of results can 
be handled together. 


The form: 
others [ ( idn : string ) ] : body 
is optional, and must appear last in a handler list. This form handies any exception not handled by other 
handlers in the list. If a variable is declared, t must be of type string. The variable, which is local to the 
handler, is assigned a lower case string representing the actual exception name; any results are 
discarded. 


Note that number and type of exception results are ignored when matching exceptions to handlers; 
only the names of exceptions are used. Thus the following ie illegal, in that int$c/v signals zero_divide 
without any results (see Section [1.4), but the closest handler has a declared variable: 


begin 
y: int :=0 
x: Int:=3/y 
except when zero_divide (z: Int): return end 
end 
except when zero_divide: return end 


A call need not be surrounded by except statements that handle ali potential exceptions. in many 
cases the programmer can prove that a particular exception will not ariee; for example, the call 
Int$aix, 7) will never signal zero_divide. However, if some call raises an exception for which there is no 
handier, then the guardian crashes due to this error®. 


*The implementation of the Argus should log unhandled exceptions in some fashion, to aid later debugging. During debugging, 
an unhandled exception would be trapped by the debugger before the crash. 
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11.3. Resignal Statement 
A resignal statement is a syntactically abbreviated form of exception handling: 
statement [ abort ] resignal name , ... 
Each name listed must be distinct, and each must be one of the condition names listed in the routine 
heading. The resignal statement acts like an except statement containing a handler for each condition 
named, where each handier simply signals that exception with exacily the same results. Thus, # the 
resignal clause names an exception with a specification in the routine heading of the form: 
name(T,, «ss, T,,) 
then effectively there is a handler of the form: 
when name (x,:T,, +=, X,: T,): [ abort ] signal name(x,, »-+, X,) 
which has an abort qualifier if and onty if the resignel statement did. As for an explicit handier of this 
form, every exception potentially handied by this implict handler must have the same number of results 
as deciared in the exception specification, and the types of the results must be included in the types listed 
in the exception specification. 


If no abort qualifier is present, then all containing actions (if any) terminated by this statement are 
committed. if the abort qualifier is present, then ail terminated actions are aborted. Unlike the leave 
statement, reeignal will abort concurrent siblings if executed within a coenter statement (see Section 
10.6). The abort qualifier can only be used textually within an enter statement, an action or topaction 
coarm of a coenter statement, or the body of a handier or creator. 


11.4. Exit Statement 
An exit statement has the form: 


[ abort ] exit name [ ( expression , ... ) ] 
An exit statement is similar to a signal statemem except that where the signal statement signals an 
exception to the calling routine, the exit statement raises the exception directly in the current routine. 
Thus an exk causes a transfer of contro! within a routine but does not terminate the routine. An 
exception raised by an exit statemem must be handied explickly by a containing except statement with a 
handler of the form: 

when name , ... [ (dec! , ... ) ] : body 
As usual, the types of the expressions in the exit statement must be included in the types of the variables 
declared in the handler. The handier must be an explicit one, |.¢., exits to the implict handiers of resignal 
statements are illegal. 


if no abort qualifier is present, then all containing actions (if any) terminated by the exit statement are 
committed. If the abort qualifier is present, then ail terminated actions are aborted. Uniike the leave 
Statement, exit will abort concurrent siblings when control flow leaves a containing coenter statement 
(see Section 10.6). The abort qualifier can only be used textually within an enter statement or an action 
or topaction coarm of a coenter statement. 
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The exit statement and the signal statement mesh nicely to form a uniform mechanism. The signal 
statement can be viewed simply as terminating a routine activation; an exit is then performed at the point 
of invocation in the caller. (Because this exit is implicit, it is not subject to the restrictions on exits listed 
above.) 


11.5. Exceptions and Actions 

A new action is created by a handier call, creator call, enter statement, or action or topaction arm of a 
coenter statement. In addition, the recover code of a guardian runs as an action. When control flows 
out of an action, that action is commited unless action is taken to prevent ts committing. To abort an 
action, i is necessary to qualify control flow statements such as ex®, signal, resignal, and leeve with the 
keyword abort (see Section 10). 


However, there is an additional complication. Not only will explicit termination of actions by exit, 
signal, and resignal statements commit actions, but aleo implicit termination by flow of control out of an 
action body when an exception raised within that body is handled outside the action’s body. Thus, if an 
exception which is raised by a call within an action is not to commit the action, then it is necessary to 
catch the exception within the action. This is particularly important when dealing with topactions. A 
common desire is to catch all “unexpected” exceptions, but still have the topaction abort. In this case, the 
catch-all exception handler must be placed inside the topaction. However, an unavailable handler must 
still be placed outside the topaction, since the two-phase commit may fail. 


An action or topaction coarm of a coenter statement will not abort its concurrent siblings when K ends 
in either normal completion of its body or by a leave statement. However, if control flows otherwise out of 
the coenter statement from within one of the coarms, the entire coenter is terminated as described in 
Section 10.6. Thus, a coenter statement should must be used carefully to ensure the proper behavior in 
case of exceptions. There may be circumstances where a separate exception handler will have to be 
used for each coarm to ensure the proper behavior, even when the exception handling is identical for 
each coarm. 


11.6. Failure Exceptions 

Argus responds to unhandled exceptions differently than CLU. In CLU, an unhandled exception in 
some routine causes that routine to terminate with the failure exception. in Argus, however, an 
unhandled exception causes the guardian that is running the routine to crash. Our motivation for this 
change is that an unhandled exception is typically a symptom of a programming error thet cannot be 
handled by the calling routine. Furthermore, crashing the guardian limits the damage that the 
programming error can cause. 


Procedures and iterators in Argus no longer have an implicit failure exception associated with them. 
Instead, such a routine may list faifure explicitly in its signals clause and failure may have any number 
(and type) of exception results. Failure should be used to indicate an unexpected (and possibly 
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catastrophic) fallure of a lower-level abstraction, for example, when there is a failure in a type parameter's 
routines (for instance in sénilar or copy operations). Another example is when there is an unwanted side 
effect, such as a bounds exception in arrayft]$elements caused by a mutation of the array argument. 
Various operations of the built-in types signal failure under such circumetances. 


For handlers and creators, faéure is used to indicate that a remote call has failed; thus the exception 
faiture( string) is implict in the type of every handler and creator (see Section 13.5). When a remote call 
terminates with the failure exception, this means that not only has this call failed, but that the call is 
unlikely to succeed if repeated. 
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12. Modules 
Besides guardian modules, Argus has procedure, Herator, cluster, and equate modules. 
module ::= { equate } guardian 

| { equate } procedure 
| { equate } kerator 
| { equate } cluster 
| { equate } equates 

Guardians are discussed in Section 13, the rest are described below. 


12.1. Procedures 

A procedure performs an action on zero or more arguments, and when i terminates it returns zero or 
more results. A procedure implements a procedural abstraction. a mapping from a set of argument 
objects to a set of result objects, with possible modification of some of the argument objects. A procedure 
may terminate in one of a number of conditions, one of these is the normal condition, while others are 
exceptional conditions. Differing numbers and types of results may be returned in the different conditions. 


The form of a procedure is: 
idn = proc [ parms ] args [ retums ] [ signais ] [ where ] 
routine_body 
end idn 
where 
args z= ([decl, ...]) 
returns se= returns ( type_spec , ... ) 
signals ss= Signals ( exception , ...) 
exception 2: name [ ( type_spec, ...) ] 
routine_body zm { equate } 
{ own_var } 
{ statement } 


In this section we discuss non-parameterized procedures, in which the parms and where clauses are 
missing. Parameterized modules are discussed in Section 12.5. Own variables are discussed in Section 
12.7. 


The heading of a procedure describes the way in which the procedure communicates with its caller. 
The args clause specifies the number, order, and types of arguments required to call the procedure, while 
the returns clause specifies the number, order, and types of results returned when the procedure 
terminates normally (by executing a return statement or reaching the end of its body). A missing retumns 
clause indicates that no results are returned. 


The signals clause names the exceptional conditions in which the procedure can terminate, and 
specifies the number, order, and types of result objects returned in each condition. Al names of 
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exceptions in the signals clause must be distinct. The idn following the end of the procedure must be the 
same as the idn naming the procedure. 


A procedure is an object of some procedure type. For a non-parameterized procedure, this type is 
derived from the procedure heading by removing the procedure name, rewriting the formal argument 
declarations with one idn per deci, deleting the /dns of all formal arguments, and finally, replacing proc by 
proctype. 


The call of a procedure causes the introduction of the formal variables, and the actual arguments are 
assigned to these variables. Then the procedure body is executed. Execution terminates when a return 
statement or a signal statement is executed, or when the textual end of the body is reached. if a 
procedure that should return results reaches the textual end of the body, the guardian crashes due to this 
error. At termination the result objects, if any, are passed back to the caller of the procedure. 


12.2. Iterators 

An iterator computes a sequence of items, one tem at a time, where an item is a group of zero or more 
objects. In the generation of such a sequence, the computation of each kem of the sequence is usually 
controlled by information about what previous tems have been produced. Such information and the way 
it controls the production of items is local to the Herator. The user of the erator is not concerned with 
how the items are produced, but simply uses them (through a for statement) as they are produced. Thus 
the Rerator abstracts from the detalis of how the production of the tems is controlled; for thie reason, we 
consider an Kerator to implement a contro! abetraction. iterators are particularly useful as operations of 
data abstractions that are collections of objects (e.9., sets), since they may produce the objects in a 
collection without revealing how the collection is represented. 


An iterator has the form: 


idn = ker [ parms ] args [ yields ] [ signais ] [ where ] 
routine_body 
end idn 
where 


yields ::= ylelds ( type_spec, ...) 
In this section we discuss non-parameterized Kerators, in which the parms and where clauses are 


missing. Parameterized modules are discussed in Section 12.5. Own variables are discussed in Section 
12.7. 


The form of an iterator is similar to the form of a procedure. There are only two differences: 

1. An iterator has a yields clause in its heading in piace of the returns clause of a procedure. 
The yields clause specifies the number, order, and types of objects yiekled each time the 
iterator produces the next Kem in the sequence. If zero objects are yiekied, then the yieids 
clause is omitted. The idn following the end of the Kerator must be the same as the idn 
naming the iterator. 


2. Within the iterator body, the yleld statement is used to present the caller with the next item 
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in the sequence. An erator terminates in the same manner as a procedure, but it may not 
return any results. 


An iterator is an object of some iterator type. For a non-parameterized Kerator, this type is derived from 
the iterator heading by removing the Iterator name, rewriting the formal argument declarations with one 
idn per deci, deleting the idns of all formal arguments, and finally, replacing Ker by Kertype. 


An iterator can be called only by a for statement or by a foreach clause in a coemer statement. 


12.3. Clusters 

A cluster is used to implement a new data type, distinct from any other built-in or user-defined data 
type. A data type (or data abstraction) consists of a set of objects and a set of primitive operations. The 
primitive operations provide the most basic ways of manipulating the objects; ukimately every 
computation that can be performed on the objects must be expressed in terms of the primitive operations. 
Thus the primitive operations define the lowest level of observable object behavior!®, 


The form of a cluster is: 
idn = cluster [ parms ] Is opidn , ... [ where ] 


cluster_body 
end idn 
where 
opidn i5= 
| transmit 


cluster_body ::= equate Ang = type_spec { equate } 
routine { routine } 


routine ::== procedure 
| iterator 
In this section we discuss non-parameterized clusters, in which the parms and where clauses are 
missing. Parameterized modules are discussed in Section 12.5. Own variables are discussed in Section 
12.7. 


The primitive operations are named by the list of opidns following the reserved word Is. All of the 
opidns in this list must be distinct. The jn following the end of the cluster must be the same as the idn 
naming the cluster. 


To define a new data type, it is necessary to choose a concrete representation for the objects of the 
type. The special equate: 


‘Readers not familiar with the concept of data abstraction might read Liskov, B. and Guttag, J., Abstraction and Specification in 
Program Development, MIT Press, Cambridge, 1986. 
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rep = type_spec 
within the cluster body identities the fype_spec as the concrete representation. Within the cluster, rep 
may be used as an abbreviation for this type_spec. 


The identifier naming the cluster is available for use in the cluster body. Use of this identifier within the 
cluster body permits the definition of recursive types. 


in addition to giving the representation of objects, the cluster must implement the primitive operations 
of the type. One exception to this, however, is the transmit operation. The transmit operation is not 
directly implemented by a cluster; instead, the cluster must implement two operations: encode and 
decode (see Section 14 for details). The primitive operations may be either procedural or control 
abstractions; they are implemented by procedures and iterators, respectively. Any additional routines 
implemented within the cluster are hidden: they are private to the cluster and may not be named directly 
by users of the abstract type. All the routines must be named by dietinct identifiers; the scope of these 
identifiers is the entire cluster. 


Outside the cluster, the type’s objects may only be treated abetractly (i.e., manipulated by using the 
primitive operations). To implement the operations, however, it is usually necessary to manipulate the 
objects in terms of their concrete representation. It is also convenient sometimes to manipuiate the 
objects abstractly. Therefore, inside the cluster it is possible to view the type's objects either abetractly or 
in terms of their representation. The syntax is defined to specify unambiguoustly, for each variable that 
refers to one of the type’s objects, which view is being taken. Thus, inside a cluster named T, a 
deciaration: 

viT 
indicates that the object referred to by vis to be treated abstractly, while a declaration: 

w: rep 
indicates that the object referred to by w is to be treated concretely. Two primitives, up and down, are 
available for converting between these two points of view. The use of up permits a type rep object to be 
viewed abstractly, while down permits an abetract object to be viewed concretely. For example, given 
the declarations above, the following two assignments are legal: 


Vv = p(w) 
w := down(v) 


Only routines inside a cluster may use up and down. Note that up and down are used merely to inform 
the compiler that the object is going to be viewed abstractly or concretely, respectively. 


A common place where the view of an object changes is at the interface to one of the type’s 
operations: the user, of course, views the object abstractly, while ineide the operation, the object is 
viewed concretely. To facilitate this usage, a special type specification, evt, is provided. The use of cvt 
is restricted to the args, retums, yielde and signals clauses of routines inside a cluster, and may be used 
at the top level only (e.g., array(cvt] is illegal). When used inside the args clause, it means that the view 
of the argument object changes from abstract to concrete when it is assigned to the formal argument 
variable. When cvt is used in the returns, yields, or signals clause, it means the view of the result object 
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changes from concrete to abstract as it is returned (or yielded) to the caller. Thus cvt means abstract 
outside, concrete inside: when constructing the type of a routine, cvt is equivalent to the abstract type, 
but when type-checking the body of a routine, cvt is equivalent to the representation type. The type of 
each routine is derived from its heading in the usual manner, except that each occurrence of cvt is 
replaced by the abstract type. The cvt form does not introduce any new ability over what is provided by 
up and down. It is merely a shorthand for a common case. 


Inside the cluster, it is not necessary to use the compound form (fype_spec$op__name) for naming 
locally defined routines. Furthermore, the compound form cannot be used for calling hidden routines. 


12.4. Equate Modules 


An equate module provides a convenient way to define a a set of equates for later use by other 
modules. 


The form of an equate module is: 


idn = equates [ parms [ where } ] 
equate { equate } 
end idn 
The usual scope rules apply. The idn following the end of the equate module must be the same as the 
idn naming the equate module. 


In this section we discuss non-parameterized equate modules. Parameterized modules are discussed 
in Section 12.5. 


An equate module defines a set of equates, that is, t defines a set of named constants. The set of 
equates is also a constant, although it is not an object. Thus the name of an equate module can be used 
in an equate, but an equate module cannot be assigned to a variable. The equates defined by an equate 
module E may be referenced using the same syntax as for naming the operations of a cluster. For 
example, an object or type named n in equate module E can be referred to as E$n. HN equate modules 
contain equates that give names to other equate modules, compound names can be used. For example: 

Alint}$8$C$name 
where A, B, and C are equate modules is legal. 


As always, equates to type specifications do not define new types but merely abbreviations for types. 
For example, in the following: 
my_types = equates 
aij = array{int] 
float = real 
end my_types 
the types my_types$ai and array[int] are equivalent. 
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12.5. Parameterized Modules 

Procedures, iterators, clusters, guardians (see Section 13), and equate modules may ail be 
parameterized. Parameterization permits a set of related abstractions to be defined by a single module. 
In each module heading there is an optional parms clause and an optional where clause (see Appendix |). 
The presence of the parms clause indicates that the module is parameterized; the where clause deciares 
the types of any operation parameters that are expected to accompany the formal type parameters. 


The form of the parms clause is: 


{parm , on. ] 
where 

parm <.= idn, oe. : type_spec 

| idn , ».. : type 

Each parm declares some number of formal parameters. Only the following types of parameters can be 
declared in a parme clause: Im, real, bool, char, string, null, and type. The declaration of operation 
parameters associated with type parameters is done in the where clause, as discussed below. The actual 
values for parameters are required to be constants that can be computed at compile-time. This 


requirement ensures that all types are known at compile-time, and permits complete compile-time type- 
checking. 


in a parameterized module, the scope rules permit the parameters to be used throughout the module. 


Type parameters can be used freely as type specifications, and all other parameters (including the 
operations parameters specified in the where clause) can be used freely as expressions. 


A parameterized module implements a set of related abstractions. A program must instantiate a 
parameterized module before & can be used; that is, t must provide actual, constant values for the 
parameters (see Section 12.6). The result of an instantiation is a procedure, Kerator, type, guardian, or 
equate module that may be used just like a non-parameterized module of the same kind. Each distinct 
list of actual parameters produces a distinct procedure, Herator, type, guardian, or equate module (see 
Section 12.6 for details). 


The meaning of a parameterized module is given by binding the actual parameters to the formal 
parameter names and deleting the parms clause and the where clause. That is, in an an instantiation of a 
parameterized module, each formal parameter name denotes the corresponding actual parameter. The 
resulting module is a regular (non-parameterized) module. in the case of a cluster some of the operations 
may have additional parameters; further bindings take place when these operations are instantiated. 


In the case of a type parameter, one can also declare what operation parameters must accompany the 
type by using a where clause. The where clause also specifies the type of each required operation 
parameter. The where clause constrains the parameterized module as well: the only operations of the 
type parameter that can be used are those listed in the where clause. 
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The form of the where clause is: 


where :.= where restriction , ... 
restriction ::= idn has oper_deci, ... 
| idn in type_set 
oper_deci ..= name , «.. : type_spec 
| transmit 
type_set 2: { idn | idn has oper_decl , ... { equate }} 
| idn 
| reference $ name 


There are two forms of restrictions. In both forms, the iniial idn must be a type parameter. The has 
form lists the set of required operation parameters directly, by means of oper_decis. The type_ spec in 
each oper_deci must be a proctype, Itertype, or creatortype (see Appendix |). The in form requires that 
the actual type be a member of a type_set, a set of types with the required operations. The two identifiers 
in the type_set must match, and the notation is read like set notation; for example, 

{t| thas f:...} 
means “the set of all types f such that thas f...". The scope of the identifier is the type_ set. 


The in form is useful because an abbreviation can be given for a type_set via an equate. if it is helpful 
to introduce some abbreviations in defining the type_set, these are given in the optional equates within 
the type_se?. The scope of these equates is the entire type_set. 


A routine in a parameterized cluster may have a where clause in its heading, and can place further 
constraints on the cluster parameters. For example, any type is permissible for the array element type, 
but the array similar operation requires that the element type have a similar operation. This means that 
array{ 7] exists for any type 7, but that array[7}$similar exists only when an actual operation parameter is 
provided for T$similar (see Section 12.6). Note that a routine need not include in its where clause any of 
the restrictions included in the cluster where clause. 


12.6. Instantiations 
To instantiate a parameterized module, constants or type specifications are provided as actual 
parameters: 
actual_parm :.= constant 
| type_actual 


type_actual ::= type_spec [ with { opbinding , ...} ] 


opbinding :2= name , ... : primary 
If the parameter is a type, the module’s where clause may require that some routines be passed as 
parameters. These routines can be passed implicitly by omitting the with clause; the routine selected as a 
defauk will be the operation of the type that has the same name as that used in the where clause. 
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Routines may also be passed explicitly by using the with clause, overriding the default. In this case, the 
actual routine parameter need not have the same name as is required in the where clause, and need not 
even be one of the type’s primitive operations. 


The syntactic sugar that allows default routines to be selected implicitly works as follows. If a generator 
requires an operation named op trom a type parameter, and if the corresponding type_actua/, TS with ( 
.. }, has no explick binding for op, then Argus adde an opbinding of ap to TS$op. (it will be an error if 
TS$op is not defined.) Thus one only has to provide an explick opbinding if the default ie unsatisfactory. 


For example, suppose a procedure generator named sort has the following heading: 
sort = procit: type}(a: arrayft]) where t has gt: proctype(t,t) returne(bool) 
and consider the three instantiations: 


sort{int with (gt: Int$gt} ] 
sort{int] 
sort{int with {it: int$it} ] 


The first two instantiations are equivalent; in the first the routine int$gt is passed explicitly, while in the 
second it is passed implicitly as the default. In the third instantiation, however, Int$/ is passed in place of 
the default. All three instantiations result in a routine of type: 

proctype (arrayjint}) 
and so each could be called by passing k an arrayjint] as an argumem. However a call of the third 
instantiation will sort its array argument In the opposite order from a call of either the first or second 
instantiation. 


Within an instantiation of a parameterized module, an operation of a type parameter named Sop 
denotes the actual routine parameter bound to op in the instantiation of that module. For example, 
suppose we make the call: 

sort{int with {gt: int$k} ] (my_ints) 
where my_ints is an array of integers. If, in the body of sort, there is a recursive call: 

sort{t with (gt: t$gt} ] (a, i, j) 
then t denotes the type int, and Sgt denotes the routine Int$/, so that the recursive sort happens in the 
correct order. 


A cluster generator may include routines with where clauses that place additional requirements on the 
Cluster’s type parameters. ES Se ene, a eee coe enn ee 
copy implementation. 


set = Cluster(t: type] is ..., copy 
where t has equal: proctype(t,t) returns(boo!l) 
rep = array(t] 


copy = proc(s: cvt) returns(cvt) where t has copy: proctype(t) returns(t) 
ae 


The intent of these subordinate where clauses is to allow more operations to be defined if the actual type 
parameter has the additional required operations, but not to make the additional operations an absolute 
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requirement for obtaining an instance of the type generator. For example, with the above definition of sei, 
Sefany] would be defined, but sefany]$copy would not be defined because any does not have a copy 
operation. We shall call the routine parameters required by subordinate where clauses optional 
parameters. 


Like regular required parameters, optional parameters can be provided when the cluster as a whole is 
instantiated and can be provided explicitly or by default. For any optional parameter op that is not 
provided explicitly by the type_actua/, TS with { ...}, we add an opbinding of opto TS$op f TS$op exists; 
otherwise the opbinding is not added. The resulting cluster contains just those operations for which 
opbindings exist for ali the required routine parameters. For example, as mentioned above, set[any] 
would not have a copy operation because any$copy does not exist and therefore the needed opbinding is 
not present. On the other hand, setfint] does have a copy operation because int$copy does exist. 
Finally, seqany with {copy: foo}], where foo is a procedure that takes an any as an argument and returns 
an any as a result, would have a copy operation. 


For an instantiation to be legal it must type check. Type checking is done after the syntactic sugars are 
applied. The types of constant parameters must be included in the declared type, type actuals must be 
types, and the types of the actual routine parameters must be included in the proctypes, itertypes, or 
creatortypes deciared in the appropriate where clauses. Of course, the number of parameters declared 
must match the number of actuals passed and with each type actual parameter there must be an 
opbinding for each required routine parameter. Hf the generator is a cluster, then opbindings must be 
provided for all operations required in the clusters where clause; opbindings can (but need not) be 
provided for optional parameters. Extra actual routine parameters are illegal. 


Because the meaning of an instantiation may depend on the actual routine parameters, type equality 
makes instances with different actual routine parameters distinct types. For example, consider the set 
type generator again; the instance 

set{ array{int] with {equal: arrayfint}$equal} ] 
is not equal to 

set{ array[int] with {equal: array[int]$simiar} | 
Intuitively these instances should be unequal because the two equa/ procedures define different 
equivalence classes and therefore the abstract behaviors of the two instances are different. However, 
optional parameters do not effect type equality. For example, 

set{array[int] with {copy: int$copy} ] 
and 

set{array[int] with {copy: my_copy} ] 
are equal types. This is intuitively justified because in each case set objects behave the same way even 
though different sets are produced when sets are copied in the two cases. 


Thus we have the following type equality rule, which defines when two type_specs denote equal types 
(after syntactic sugars are applied). A similar notion is also needed for routine equality. A formal type 


84 Modules 


identifier is equal only to itself for type checking purposes. Otherwiee, two type names denote equal 
types if they denote the same Description Unit (DU).'! Similarly, Argus compares the names of routine 
formats or the DUs of routines, or checks that they are the same operation in equal types. To decide the 
equality of two type generator instantiations: 

Ty with {op,: act,, ... OP,,: ACt,} , ... t, with {...} ] 

a 

Tit,’ with {op,: act,’, ... OP,,: acty’}, .... t, with (...}] 
Argus first checks whether: 

1. Tand T denote the same DU, and whether 

2. they have the same number of type_actuais, and t, is equal to #,’, etc. 
Second, any optional parameter opbindings in either instantiation are deleted. After this step, Argus 
checks that for each corresponding type_ actual there is the same number of opbindings and that each 
corresponding opbinding is the same. (That is, the corresponding actual routines are equal.) The order 
of the actual routine parameters does not matter, since Argus matches opbindings by operation names. 
(The definition of routine equality for instantiations of routine generators is similar.) This definition, for 
example, tells us that 

set{ array[int] with (equal: array[int]$equal} } 
is different from 

set{ array(int] with {equal: arrayfint}$similar} | , 
(assuming set requires an equal operation from its type parameter). It also telis us that: 

set{ Int with {equal: foo, copy: bar} } 
and 

set[ Int with {equal: foo, copy: xerox} ] 
are equal (assuming copy is required only by the sefint]$copy operation). 


This type equality rule allows programmers to controi what requirements affect type equality by 
choosing whether to put them on a cluster or on each operation. A requirement on the cluster should be 
used whenever the actuals make some difference in the abstraction. For example, in the set cluster, the 
type parameter’s equal operation should be required by the cluster as a whole, since using different 
equality tests for a set's objects causes the set's behavior to change. 


One can require that a type parameter, say f, be transmissible by stating the requirement: 
t has transmit 
This requirement is regarded as a formal parameter deciaration for a special “transmit actual", but Argus 
does not provide syntax for passing it explicitly. The “transmit actual” is passed implicitly just when the 
actual type parameter is transmissible and the generator requires it. 


‘This is name equality uniess the type environment has synonyms for types. 
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12.7. Own Variables 

Occasionally i is desirable to have a module that retains information internally between calls. Without 
such an ability, the information would either have to be reconstructed at every call, which can be 
expensive (and may even be impossible # the information depends on previous calis), or the information 
would have to be passed in through arguments, which is undesirable because the information is then 
subject to uncontrolled modification in other modules (but see also the binding mechanism described in 
Section 9.8). 


Procedures, iterators, handlers, creators, and clusters may ail retain information through the use of 
own variables. An own variable is similar to a normal variable, except that it exists for the Me of the 
program or guardian, rather than being bound to the life of any particular routine activation. Syntactically, 
own variable deciarations must appear immediately after the equates in a routine or cluster body; they 
cannot appear in bodies nested within statements. Declarations of own variables have the form: 

own_var :.= own deci 
| own idn : type_spec := expression 
| own dec! , ... = call [ @ primary ] 
Note that initialization is optional. 


The own variables of a module are created when a guardian begins execution or recovers from a 
crash, and they always start out uninitialized. The own variables of a routine (including cluster 
operations) are initialized in textual order as part of the first call of an operation of that routine (or the first 
such call after a crash), before any statements in the body of the routine are executed. Cluster own 
variables are initialized in textual order as part of the first call of the first cluster operation to be called 
(even if the operation does not use the own variables). Cluster own variables are initialized before any 
operation own variables are initialized. Argus insures that only one process can execute a cluster's or a 
routine’s own variable inilalizations. 


Aside from the placement of their declarations, the time of their initialization, and their Metime, own 
variables act just like normal variables and can be used in all the same places. As with normal variables, 
an attempt to use an uninitialized own variable (if not detected at compile-time) will cause the guardian to 
crash. 


Declarations of own variables in different modules always refer to distinct own variables, and distinct 
guardians never share own variabies. Furthermore, own variable declarations within a parameterized 
module produce distinct own variables for each distinct instantiation of the module. For a given 
instantiation of a parameterized cluster, all instantiations of the type's operations share the same set of 
cluster Own variables, but distinct instantiations of parameterized operations have distinct routine own 
variables. 


Declarations of own variables cannot be enciosed by an except statement, so care must be exercised 
when writing initialization expressions. if an exception ie raised by an inkialization expression, it will be 
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treated as an exception raised, but not handled, in the body of the routine whose call caused the 
initialization to be attempted. Thus, the guardian will crash due to this error. 
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stabie buffer: atomic_array[int] := atomic_array/int}$new ( ) 

cache: array[int] := array[inti$new () 
then the atomic_ array object denoted by buffer would survive a guardian crash, but the array object 
denoted by cache would not. See Section 13.3 for more details of crash recovery. Volatile variables can 
be assigned wherever an assignment statement is legal. However, stable variables may only be 
assigned by an initialization when declared or in the body of a creator. The initializations of both stable 
and volatile variables are executed within an action, as described below. However, the stable variables 
are not reinitialized upon crash recovery, whereas volatile variables are reintialized upon crash recovery. 


Stable variables should denote resilient objects (see Section 15.2), because only resilient data objects 
(reachable from the stable variables) are written to stable storage when a topaction commits. (This can 
be ensured by having stable variables only denote objects of an atomic type or objects protected by 
mutex.) Non-resilient objects stored in stable variables are only written to stable storage once, when the 
guardian is created. Furthermore, the stable variables should usually denote atomic objects, because the 
stable variables are potentially shared by all the actions in a guardian. 


13.2. Creators 

A guardian definition must provide one or more creators. The names of these creators must be lieted 
in the guardian header (internal creators are not allowed); each such name must correspond to a single 
creator definition appearing in the body of the guardian definition. 


A creator defintion has the same form as a procedure definition, except that creators cannot be 
parameterized, and the reserved word creator is used in place of proc: 


idn = creator ([ args ]) [ retums ] [ signats ] 
routine_body 


end idn 
The initial idn names the creator and must agree with the final dn. The types of all arguments and all 
results (normal and exceptional) must be transmissible. 


A Creator is an object of some creator type. This type is derived from the creator heading by removing 
the creator name, rewriting the formal argument declarations with one idn per deci, deleting the idns of ail 
formal arguments, deleting any failure or unavailable signals, and finally, replacing creator by 
creatortype. The signals failure(string) and unavailable(string) are implicit in every creator type (since 
they can arise from any creator call). However, if these signals are raised explicitly by a creator, they 
must be listed in the signals clause with string result types. 


The semantics of a creator call are explained in Section 8.4. Typically, the body of a creator will 
initialize some stable and volatile variables. it can aiso retum the name of the guardian being created 
using the expression self. Since the creator (and the state initialization) runs as an action, the creator 
terminates by committing or aborting. if it aborts, the guardian is destroyed. If it commits, the guardian 
begins to accept handier calis, and runs the background code, if any (see below). if an ancestor of the 
creator aborts, the guardian is destroyed. Hf the creator and all ks ancestors commit, the guardian 
becomes permanent, and will survive subsequent crashes. 
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13.3. Crash Recovery 

Once a guardian becomes permanent, it will be recreated automatically after a crash with its stable 
variables initialized to the same state they were in at the last topaction commit before the crash. The 
volatile variables are then initialized (in declaration order) by a topaction. To aid in this reinitialization, the 
guardian definition can provide a recover section. 

recover body end 

to be run, as part of this topaction, after the initializations attached to the volatile variable declarations are 
performed. The recover section commits when control reaches the end of the body, or when a return 
statement is executed. The recover section may abort by executing an abort return statement or as a 
result of an unhandied exception. The guardian crashes if the recover section aborts. 


13.4. Background Tasks 
Tasks that must be performed periodically, independent of handler calls, can be defined by a 
background section. 
background body end 
The system creates a process to run this body as soon as creation or recovery commis successfully. 
The body of the background section does nof run as an action; typically kt will perform a sequence of 
topactions. 


If the background process finishes. executing ts body (either by reaching the end of the block or by 
returning), the process terminates, but the guardian continues to execute incoming handier calls. 


13.5. Handlers and Other Routines 
Typically, the principal purpose of a guardian is to execute incoming handler calls. A guardian accepts 
handier calls as soon as creation or recovery commits. 


The guardian header lists the names of the externally available handlers. Each handler listed must be 
defined by a handier definition. Additional handler definitions may also be given, but these handlers can 
be named only within the guardian to which they belong. 


A handler definition has the same form as a procedure definition, except that handlers cannot be 
parameterized, and the reserved word handier is used in place of proc: 
idn = handler ([ args ]) [ returns ] [ signats ] 
routine_body 
end idn 
The initial idn names the handler and must agree with the final jan. The types of all arguments and all 
results (normal and exceptional) must be transmissibie. 


A handler is an object of some handler type. This type is derived from the handier heading by 
removing the handler name, rewriting the formal argument declarations with one idn per deci, deleting the 
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consumption. The spooler provides an operation for adding (object, consumer) pairs, and for destroying 
the guardian. 


Figure 13-1: Spooler Guardian 


spooler = guardian [t: type] Is create handies eng, finish 
where t has tranemk 


utype = handiertype (1) 
entry = structfobject: t, consumer: utype] 
queue = semiqueuefentry] 


stable state: queue := queue$create() 


background 
while true do 
enter topaction 
@: entry := queve$deq(state) 
@.consumer(e.object) 
except when unavailable (*): abort leave end 
end except when failure, unavailable (*): end 
end 
end 


create = creator () returns (spooler{t)) 
return(seif) 
end create 


enq = handier (item: t, user: utype) 
queue$end(state, entry${object: tem, consumer: user}) 
end eng 
finish = handier () 
terminate 
end finish 


end spooler 


The spooler guardian is parameterized by the type of object to be stored. The eng handler takes an 
object of this type, and a handler for sending the object to the coneumer, and adds this information to the 
stable state of the spooler. This state is an object of the semiqueue abstract data type'*. Each entry in 
the semiqueue is a structure containing a stored object and its corresponding consumer handler. The 
background code of the guardian runs an infinite loop that starts a topaction, removes an entry from the 
queue, and sends the object using the associated handier. 


Note that an unavailable exception arising from this handler call is caught inside the topaction, so that 
an explicit abort can be performed. If the exception were caught outside the topaction, it would cause the 


See W. Weihl and B. Liskov, "lmplementation of Resilient, Atomic Data Types", in ACM Transactions on Programming 
Languages and Systems, volume 7, number 2, (April 1965), pages 244-260. 
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topaction to commit, and the entry would be removed without being consumed. Note also that failure is 
caught outside the topaction, since f an encode were to fall, or # the guardian did not exist, the 
background process might aimlessly loop forever, because it would not be able to remove that entry. 


A more extended example of a distributed system appears in the paper Liskov, B. and Scheifler, R., 
“Guardians and Actions: Linguistic Support for Robust, Distributed Programs,” ACM Transactions on 
Programming Languages and Systems, volume 5, number 3, (July 1983), pages 381-404. 
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14.3. Transmit for Abstract Types 

The type implemented by a cluster is transmissible if the reserved word tranamit appears in the Is-list 
at the head of the cluster. Unlike the other operations provided by a type, the transmit operation cannot 
be called directly by users, and in fact is not implernented directly in the cluster. Instead, transmit Is 
implemented indirectly in the following way. Each transmissible type is given a canonical representation, 
Called its external representation type. The external representation type of an abstract type T is any 
convenient transmissible type XT. This type can be another abstract type if desired; there is no 
requiremem that XT be a built-in type. Intuitively, the meaning of the extemal representation is that 
values of type X7 will be used in messages to represemt values of type 7. The choice of extemal 
representation type is made for the abstract type as a whole and must be used in every implementation of 
that type. (There are currently no provisions for changing the extemai representation of a type once it 
has been established in the library.) 


Each implementation of the abstract type 7 must provide two operations to map between values of the 

abstract type and values of the external representation type. There is an operation 

encode = proc (a: T) returns (XT) [ signals (failure(string)) ] 
to map from T values to X7 values (for sending messages) and an operation 

decode = proc (x: XT) retums (T) [ signais (failure(string)) ] 
to map from XT values to T values (for receiving messages). The tranemit operation for 7 is defined by 
the following identity: 

T$transmit (x) = T$decode (XT$transmk (T$Sencode(x))) 
Intuitively, the correctness requirement for encode and decode is that they preserve the abstract T values: 
encode maps a value of type 7 into the XT value that represents it, while decode performs the reverse 
mapping'4. 


Encode and decode are called implicitly by the Argus system during handler and creator calls. if 
encode and decode do not appear in the cluster’s is-list, then they will be accessible to the Argus system, 
but may not be named directly by users of the type. A fad#ure exception raised by one of these operations 
will be caught by the Argus system and resignatiied to the caller (see Section 8.3). 


An abstract type's encode and decode operations should not cause any side effects. This is because 
the number of calls to encode or decode is unpredictable, since arguments or results may be encoded 
and decoded several times as the system tries to establish communication. [in addition, verifying the 
correctness of tranemission is easier « encode and decode are simply traneformations to and from the 
extemal representation. 


When defining a parameterized module (see Section 12.5), it may be necessary to require a type 
parameter to be transmissible. A special type restriction: 


‘4Herlihy, M. and Liskov, B., "A Value Transmission Method for Abstract Data Types", ACM Transactions on Programming 
Languages and Systems, volume 4, number 4, (Oct. 1962), pages 527-551. 
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has transmit 
is provided for this purpose. To permit instantiation only with transmissible type parameters, this 
restriction should appear in the where clause of the cluster. Aitematively, by placing identical where 
clauses in the headings of encode and decode procedures, one can eneure that an instantiation of the 
cluster is transmissible only # the type parameters are transmissible (see Section 12.5). 


As an example, Figure 14-1 shows part of a cluster defining a key-item tabie that stores pairs of values, 
where one value (the key) is used to retrieve the other (the fem). The key-tem table type has operations 
for creating empty tables, inserting pairs, retrieving the tem paired with a given key, deleting pairs, and 
iterating through all key-item pairs. The table is represented by a sorted binary tree, and its extemal 
represemation is an array of key-item pairs. The table type is transmissible only if both type parameters 
are transmissible. 


Figure 14-1: Partial implementation of table. 


table = cluster [key, item: type] Is create, insert, lookup, alipairs, delete, transmit, ... 
where key has i: proctype (key, key) returne (bool), 
equal: proctype (key, key) returns (bool) 


pair = record[k: key, i: Kem] 

nod = record{k: key, i: tem, left, right: table[key, tem] 
rep = varlant{empty: null, some: nod] 

xrep = array[pair] % the external representation type 


% The internal representation is a sorted binary tree. All pairs in the table 
% to the left (right) of a node have keys fess than (greater than) the key in 
% that node. 


% ... other operations omitted 


encode = proc (t: table[key, item]) returns (xrep) 
where key has tranemit, tem has tranemit 
xr: xrep := xrep$new() % create an empty array 
% use alipairs to extract the pairs from the tree 
for p: pair in alipairs(t) do 
% Add the pair to the high end of the array. 
xrep$addh(xr, p) 
end 


return(xr) 
end encode 


decode = proc (xtbi: xrep) returns (table[key, item]) 
where key has transmit, Kem has tranemik 
t: tablefkey, Hem] := create() % create empty table 
for p: pair In xrep$elements(xr) do 
% xrep$elements yields all elements of array xr 
a p.key, p.ittem) % enter pair in table 


return(t) 
end decode 
end table 
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14.4. Sharing 

When an object of structured built-in type is encoded and decoded, sharing among the object's 
components is preserved. For exampie, let a be an array 7] object such that afi] and ajj] refer to a single 
object of type 7. If a2 is an array{7] object created by transmitting a, then a2/i] and a2fj] also name a 
single object of type T. 


Ail sharing is preserved among all components of mukiple objects of built-in type when those objects 
are encoded together. Thus, sharing is preserved for objects that are arguments of the same remote call 
or are results of the same remote call, unless the arguments are encoded at different times (see the 
discussion of the bind expression in Section 9.8). For exampie, let a and b be array{7] objects such that 
afi] and b{j] reter to a single object of type 7. Hf a2 and &2 are amays created by sending a and b as 
arguments in a single handler call, then a2{i] and b2{/] also refer to a single object. 


Whether an abstract type’s tranemit operation preserves sharing is part of that type’s specification, but 
sharing should usually be preserved for abstract types. in the key-tem table implementation of Figure 
14-1, there are two types of sharing that should be preserved: sharing of keys and kems among multiple 
tables sent in a single message, and sharing of tems bound to the same key in a single table. The 
key-item table example shows how to implement an abstract type whose tranemission preserves sharing 
by choosing an extemal representation type whose transmit operation preserves sharing. 


Care must be taken when the references among objects to be tranemitted are cyclic, as in a circular 
list. Decoding such objects can result in a failure exception unless encode and decode are implemented 
in one of two ways: 

1. the internal and external representation types are identical and encode and decode return 
their argument object without modifying it or accessing its components, or 
2. the external representation object must be free of cycles. 
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15. Atomic Types 

In Argus, atomicity is erforced by the objects shared among actions, rather than by the individual 
actions themselves. Types whose objects ensure atomicity of the actions sharing them are called atomic 
types; objects of atomic types are called atomic objects. In thie chapter we define what it means for a 
type to be atomic and describe the mechanisms provided by Argus to support the implementation of 
atomic types. 


Atomicity consists of two properties: serializability and recoverability. An atomic type’s objects must 
synchronize actions to ensure that the actions are serializable. An atomic type’s objects must also 
recover from actions that abort to ensure that actions appear to execute either completely or not at all. 


In addition, an atomic type must be resilient. the type must be implemented so that its objects can be 
saved on stable storage. This ensures that the effects of an action that commits to the top (that is, an 
action that commits, as do all of its ancestors) will survive crashes. 


This chapter provides definitions of the mechanisms used for user-defined types in Argus. For 
example implementations, see Weihi, W. and Liskov, B., “implementation of Resilient, Atomic Data 
Types,” ACM Transactions on Programming Languages and Systems, volume 7, number 2 (April 1985), 
pages 244-269. 


The remainder of this chapter is organized as follows. In Section 15.1 and Section 15.2, we present 
the details of the mechanisms. Section 15.1 focuses on synchronization and recovery of actions, while 
Section 15.2 deals primarily with resilience. In Section 15.3, we discuss some guidelines to keep in mind 
when using the mechanisms described in Section 15.1 and Section 15.2. In Sections 15.4 and 15.5, we 
define more precisely what it means for a type to be atomic. Finally, in 15.6, we discuss some details that 
are important for user-defined atomic types that are implemented using multiple mutexes. 


15.1. Action Synchronization and Recovery 
in this section we describe the mechanisms provided by Argus to support synchronization and recovery 


of actions. These mechanisms are designed specifically to support implementations of atomic types that 
allow highly concurrent access to objects. 


Like a non-atomic type, an atomic type is implemented by a cluster that defines a representation for the 
objects of the type, and an implementation for each operation of the type in terms of that representation. 
However, the implementation of an atomic type must solve some problems that do not occur for ordinary 
types, namely: synchronizing concurrent actions, making visible to other actions the effects of committed 
actions, hiding the effects of aborted actions, and providing resilience against crashes. 


An impiementation of a user-detined atomic type must be abie to find out about the commits and aborts 
of actions. In Argus, implementations use objects of built-in atomic types for this purpose. The 
representation of a user-defined atomic type is typically a combination of atomic and non-atomic objects; 
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Changed = proc (m: mutex{T]) 
is provided for notifying the system that an existing mutex object should be written to stable storage. 
Calling this operation will cause the object to be written to stable storage (ascurning it is accessible) by 
the time the action that executed the changed operation commits to the top. Sometime after the action 
calls changed, and before is top-level ancestor commits, the system will copy the mutex object to stable 
storage. Changed must be called from a process running an action. 


Mutex objects also define how much information must be written to stable storage. Copying a mutex 
object involves copying the contained object. By choosing the proper granularity of mutex objects the 
user can control how much data must be written to stable storage at a time. For example, a large data 
base can be broken into partitions that are written to stable storage independently by dividing t among 
several mutex objects. Such a division can be used to limit the amount of data written to stable storage 
by calling changed only for those partitions actually modified by a committing action. 


In copying a mutex object, the system will copy all objects reachable from it, excluding other mutex or 
built-in atomic objects. A contained mutex or built-in atomic object wil be copied onty if necessary; that is, 
only if it is: 

ea mutex object for which (a descendant of) the completing action called the changed 
operation, 
a built-in atomic object that was modified by the action, or 
e a newly accessible object for which no stable copy exists. 
Furthermore, the component is copied independently of the containing mutex object; they may be copied 
in either order (or simultaneously), subject to the constraint that the system cannot copy a mutex object 
without first gaining possession of it. 


Finally, mutex objects can be used to ensure that information is in a consistent state when it is written 
to stable storage. The system will gain possession of a mutex object before writing it to stable storage. 
By making all modifications to mutex objects inside seize statements, the user's code can prevent the 
system from copying a mutex object when it is in an inconsistent state. 


Some details of the effect of changed are important for atomic types that are implemented as multiple 
mutexes. These details are presented in Section 15.6. ; 


15.3. Guidelines 

This section discusses some guidelines to be followed when implementing atomic types. There are 
additional guidelines to follow when muttiple mutexes are used to implement an atomic type; those 
guidelines are discussed in Section 15.6. 


An important concept for describing the resilience of user-defined atomic types is synchrony. An object 
is synchronous if it ls not possible to observe that any portion of the object is copied to stable storage at a 
different time from any other portion. For example, an object of type array{mutex{int]] would not be 
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synchronous, because elements of the array can be copied at different times. A type ts synchronous if all 
of its objects are synchronous. Whether a type is synchronous or not is an important property of Its 
behavior and should be stated in its specification. The built-in atomic types are synchronous; user- 
defined types must also be synchronous if they are to be atomic. 


To ensure the resilience and serializabilty of a user-defined atomic type independently of how it Is 
used, the form of the rep for an atomic type should be one of the following possibilities. 
1. The rep is itself atomic. Note that mutex is not an atomic type. 


2. The rep is mutex{f] where tis a synchronous type. For example, f could be atomic, or it 
could be the representation of an atomic type, if the operations on the this fictitious atomic 
type are coded in-line so that the entire type behaves atomically. 

3. The rep is an atomic collection of mutex types containing synchronous types. 


4. The rep is a mutable collection of synchronous types, and objects of the representation 
type are never modified after they are initialized. That is, mutation may be used to create 
the initial state of such an object, but once this has been done the object must never be 
modified. 


When using mutex objects, there are a few rules to remember. First, changed must be called after the 
last modification (on behalf of some action) to the contained object. This is true because the Argus 
system Is free to copy the mutex to stable storage as soon as changed has been called. 


In addition, changed should be called even if the object is not accessible from the stabie variables of a 
guardian. In part this rule is just an example of separation of concerns: the implementation of the atomic 
type should be done independently of any assumptions about how the object will be used. Therefore the 
type should be implemented as if its objects were accessible from the stable variables of some guardian. 
However, in addition, # this rule is not followed, it is possible that stable storage will not be updated 
properly. This situation can occur if an object was accessible, then becomes inaccessible, and later 
becomes accessible again. The system guarantees that no problems arise if changed is always called 
after the last modification to the object. 


Mutex objects should not share data with one another, unless the shared data is atomic or mutex. 
One reason for this rule is that in copying mutex objects to stable storage Argus does not preserve this 
kind of sharing. 


A final point about mutex objects is that it is unwise to do any activity that is likely to take a long time 
inside a seize statement. For example, a handler call should not be done from inside a seize statement if 
possible. Also, it is unwise to wait for a lock inside a seize unless the programmer can be certain that the 
lock is available or will be soon. Otherwise, a deadiock may occur. An example of where waiting for a 
lock in a nested seize statement is safe is where all processes seize the two mutex objects in the same 
order. 


15.4 A Prescription for Atomicity 101 


15.4. A Prescription for Atomicity 

In this section, we discuss how to decide how much concurrency is possible in implementing an atomic 
type. In writing specifications for atomic types, we have found % helpful to pin down the behavior of the 
operations, initially assuming no concurrency and no failures, and to deal with concurrency and failures 
later. in other words, we imagine that the objects will exist in an environment in which all actions are 
executed sequentially, and in which actions never abort. 


Although a sequential specification of this sort does not say anything explick about permissible 
concurrency, t does impose limits on how much concurrency can be provided. Hnplemerntations can 
differ in how much concurrency Is provided, but no implementation can exceed these limits. Therefore, it 
is important to understand what the limits are. 


This section and the following section together provide a precise definition of permiesible concurrency 
for an atomic type. This definition is based on two facts about Angus and the way i supports 
implementations of atomic type. First, in implementing an atomic type, & Is only necessary to be 
concerned about active actions. Once an action has committed to the top, it is not possible for it to be 
aborted later, and its changes to atomic objects become visible to other actions. So, for example, an 
implementation of an atomic type needs to prevent one action from observing the modifications of other 
actions that are still active, but t does not have to prevent an action from observing modifications by 
actions that have already committed. Second, the only method available to an atomic type for controlling 
the activities of actions is to delay actions while they are executing operations of the type. An aiomic type 
cannot prevent an action from calling an operation, although k can prevent that call from proceeding. 
Also, an atomic type cannot prevent an action that previously finished a call of an operation from 
completing either by committing or by aborting. 


Given the sequential specitication of the operations of a type, these facts lead to two constraints on the 
concurrency permitted among actions using the type. While an implementation can allow no more 
concurrency than permitted by these constraints, some implementations, like that for the buli-in type 
generator atomic__ array (see Section 11.10), may allow less concurrency than permitted by their 
sequential specifications and our concurrency constraints. 


The first constraint is that 


e an action can observe the effects of other actions only # those actions committed relative to 
the first action. 


This constraint implies that the results returned by operations executed by one action can reflect changes 
made by operations executed by other actions only # those actions committed relative to the first action. 
For example, in an atomic array a, if one action performs a store(a, 3, 7), a second (unrelated) action can 
receive the answer "7" from a call of feich(a, 3) only if the first action committed to the top. ff the first 
action is still active, the second action must be delayed until the first action completes. This first 
constraim supports recoverability since it ensures that effects of aborted actions cannot be observed by 
other actions. It also supports serializability, since k prevents concurrent actions from observing one 
another's changes. 
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However, more is needed for serializability. Thus, we have our second constraint: 


© operations executed by one action cannot invalidate the results of operations executed by a 
concurrent action. 


For example, suppose an action A executes the size operation on an atomic array object, receiving n as 
the result. Now suppose another action B is permitted to execute add. The addh operation will increase 
the size of the array to n + 1, invalidating the results of the size operation executed by A. Since A 
observed the state of the array before B executed addh, A must precede B in any sequential execution of 
the actions (since sequential executions must be consistent with the sequential specifications of the 
objects). Now suppose that B commits. By assumption, A cannot be prevented from seeing the effects of 
B. if Aobserves any effect of 8, kt will have to follow B in any sequential execution. Since A cannot both 
precede and follow B in a sequential execution, serializabllity would be violated. Thus, once A executes 
size, an action that calls addh must be delayed until A completes. 


15.5. Commuting Operations 

To state our requirements more precisely, consider a simple situation involving two concurrent actions 
each executing a single operation on a shared atomic object X. (The actions may be executing 
operations on other shared objects also, but in Argus each object must individually ensure the atomicity of 
the actions using it, so we focus on the operations involving a single object.) A fairly simple condition that 
guarantees serializability is the following. Suppose X is an object of type 7. X has a current state 
determined by the operations performed by previously committed actions. Suppose O, and O, are two 
executions of operations on Xin its current state. (O, and O, might be executions of the same operation 
or different operations.) If O, has been executed by an action A and A has not yet committed or aborted, 
O, can be performed by a concurrent action B only if O, and O, commute: given the current state of X, 
the effect (as described by the sequential specification of 7) of performing O, on X followed by O, is the 
same as performing O, on X followed by O;. It is important to realize that when we say “effect” we 
include both the results returned and any modifications to the state of X. 


The intuitive explanation of why the above condition works is as follows. Suppose O, and O, are 
Performed by concurrent actions A and B at X. if O, and O, commute, then the order in which A and 8 
are serialized globally does not matter at X. If A is serialized betore B, then the local effect at X is as if O, 
were performed before O,, while if B is serialized before A, the local effect is as f O, were performed 
before O,. But these two effects are the same since O, and O, commute. 


The common method of dividing operations into readers and writers and using read/write locking works 
because it allows operations to be executed by concurrent actions only when the operations commute. 
More concurrency is possible with our commutativity condition than with readers/writers because the 
meaning of the individual operations and the arguments of the calls can be considered. For example, 
Calis of the atomic array operation addh always commute with calis of adof, yet both these operations are 
writers. As another example, sfora(X, /, e,) and store{X, j, e.) commute if / + /. 


We require only that O, and O, commute when they are executed starting in the current state. 
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Consider a bank account object, with operations to deposit a sum of money, to withdraw a sum of money 
(with the possible result that it signals insufficient funde W the curremt balance is less than the sum 
requested), and to examine the current balance. Two withdraw operations, say for amounts m and n, do 
not commute when the current balance is the maximum of m and n: either operation when executed in 
this state will succeed in withdrawing the requested sum, but the other operation must signal insufficient 
funds if executed in the resuiting state. They do commute whenever the current balance is at least the 
sum of m and n. Thus if one action has executed a withdraw operation, our condition allows a second 
action to execute another withdraw operation while the first action is still active as long as there are 
sufficient funds to satisfy both withdrawal requests. 


Our condition must be extended to cover two additional cases. First, there may be more than two 
concurrent actions at a time. Suppose A,,...,4, afe concurrent actions, each performing a single 
operation execution O,,...,0,, respectively, on X. (As before, the concurrent actions may be sharing 
other objects as well.) Since A,,...,A, are permitted to be concurrent at X, there is no local control over 
the order in which they may appear to occur. Therefore, all possible orders must have the same effect at 
X. This is true provided that all permutations of O,,....0, have the same effect when executed in the 
current state, where effect includes both results obtained and modifications to X. 


The second extension acknowledges that actions can perform sequences of operation executions. 
Consider concurrem actions A,,...,A, each performing a sequence S,,...,5,, respectively, of operation 
executions. This is permissible # ali sequences S,,,...,S,,, obtained by concatenating the sequences 
S,,....S, in some order, produce the same effect. For example, suppose action A executed addh 
followed by remh on an array. This sequence of operations has no net effect on the array. It is then 
permissible to allow a concurrent action B to execute size on the same array, provided the answer 
returned is the size of the array before A executed adah or after it executed remh. 


Note that in requiring certain sequences of operations to have the same effect, we are considering the 
effect of the operations as described by the specification of the type. Thus we are concerned with the 
abstract state of X, and not with the concrete state of Its storage representation. Therefore, we may allow 
two operations (or sequences of operations) that do commute in terms of their effect on the abstract state 
of X to be performed by concurrent actions, even though they do not commute in terms of their effect on 
the representation of X. This distinction between an abstraction and its implementation is crucial in 
achieving reasonable performance. 


It is important to realize that the constraints that are imposed by atomicity based on the sequential 
specification of a type are only an upper bound on the concurrency that an implementation may provide. 
A specification may contain additional constraints that further constrain implementations; these 
constraints may be essential for showing that actions using the type do not deadiock, or for showing other 
kinds of termination properties. For example, the specification of the built-in atomic types explicitly 
describes the locking rules used by their implementations; users of these types are guaranteed that the 
buiR-in atomic types will not permit more concurrency than allowed by these rules (for instance, actions 
writing different components of an array, or different fields of a record, cannot do so concurrently). 
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1. Before that crash, B also committed to the top. in this case the data read back from stable 
Storage is, in fact, consistent, since it must reflect B’s changes to both the first and second 
semiqueues. 


2. B aborted or had not yet committed before the crash. In ether case, B aborts. Therefore, 
the changes made to the first semiqueue by B will be hidden by the semiqueuve 
implementation: at the abstract level, the two semiqueues do have the same siate. 


The point of the above example is that if the objects being written to stable storage are atomic, then the 
fact that they are written incrementally causes no problems. 


On the other hand, when an atomic type is implemented with a representation consisting of several 
mutex objects, the programmer must be aware that these objects are written to stable storage 
incrementally, and care must be taken to ensure that the representation invariart is stil preserved and 
that information is not lost in spite of incremental writing. Hf the implementation of a type requires that one 
mutex object (call it M7) be written to stable storage before another (call t M2), then the write of M1 must 
be contained in an action that commits to the top before the action that writes M2 is run. 
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We use an extended BNF grammar to define the eytiex. The gansel form of « production is 
nonterminal «-= ahemative 


The following extensions are used: 
@ , oss & list of one or more as-separcted hy commas: "x" or "a, a” oF “a, a, a”, otc. 
{a} & sequence of zero or more as: * "or “a er *a a", otc. 
[a] an eptionedl a: °* or “a”. >. 
symbols are nonalphabetic and appear in normal tece. 


so 


Cluster ht ~ chuntar {| we}: on ee 


routine 


procedure 


iterator 


creator 


handler 


Syntax 


procedure 
iterator 


idn = proc [ parms ] args [ retums ] [ signats ] [ where ] 
routine_body 
end idn 


idn = iter [ parms ] args [ yields ] [ signals ] [ where ] 
routine_body 
end idn 


idn = creator args [ retums ] [ signals ] 
routine_body 
end idn 


idn = handier args [ retums ] [ signals ] 
routine_body 
end idn 


{ equate } 

{ own_var } 
{ statement } 
[parm , o.] 


idn , «.. : type 
idn , ae. : type_spec 


([dect, ... ]) 

idn , ... : type_spec 
returns ( type_spec, ...) 
yields ( type_spec, ... ) 
signats ( exception , ... ) 


name [ ( type_spec , ...) ] 
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opidn 


where 


restriction 


type_set 


Oper_deci 


constant 


state_deci 


equate 


own_var 


idn 
transmit 


where restriction , ... 


idn has oper_deci , ... 
idn In type_set 


{ idn | idn has oper_deci, ... { equate }} 
idn 
reference $ name 


Name , «.. : type_spec 
transmit 


expression 
type_spec 


[ stable ] deci 
[ stable ] idn : type_spec := expression 
[ stable ] deci, ... := call 


idn = constant 
idn = type_set 
idn = reference 


own deci 
own idn : type_spec := expression 
own deci , as. := call [ @ primary ] 
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statement 


enter_stmt 


Syntax 


dec! 

idn : type_spec := expression 

decl , «.. = call [ @ primary ] 

idn , -. = call [ @ primary ] 

idn , we» = expression , o.. 

Primary . name := expression 

primary [ expression ] := expression 

call [ @ primary ] 

fork call 

seize expression do body end 

pause 

terminate 

enter_stmt 

coenter coarm { coarm } end 

[ abort ] leave 

while expression do body end 

for_stmt 

if_stmt 

tagcase_stmt 

tagtest_stmt 

tagwak_stmt 

[ abort ] return [ ( expression , ...) ] 

yield [ ( expression, ...) ] 

[ abort ] signa name [ ( expression, ...) ] 

[ abort ] exit name [ ( expression, ... ) ] 

[ abort ] break 

[ abort ] continue 

begin body end 

statement [ abort ] resignal name , ... 

statement except { when_handler } 
[ others_handier ] 
end 


enter topaction body end 
enter action body end 
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coarm 


armtag 


for_stmt 


if_stmt 


tagcase_stmt 


tagtest_stmt 


tagwait_stmt 


tag_arm 
atag_arm 


tag_kind 


when_handler 


others_handier 


body 


armtag [ foreach deci , ... In call ] body 


action 


topaction 
process 


for [ dec! , ... ] In call do body end 
for [ idn , ... ] In call do body end 


If expression then body 
{ elseif expression then body } 
[ elee body } 
end 


tagcase expression 
tag_arm { tag_arm } 
[ others : body ] 
end 


tagtest expression 
atag_arm { atag_arm } 
[ others : body ] 
end 


tagwalt expression 
atag_arm { atag_arm } 
end 


tag name , ... [ ( idn : type_spec ) ] : body 
tag_kind name , ... [ ( idn : type_spec ) ] : body 


tag 
wtag 


when name , ... [ ( dect , ... )] : body 
when name , ... (*) : body 


others [ ( idn : type_spec ) ] : body 


{ equate } 
{ statement } 


111 


112 


type_spec 


field_spec 


reference 


actual_parm 


type_actual 


opbinding 


sequence [ type_actual ] 

array [ type_actual ] 

atomic_array [ type_actual | 

struct { field_spec , ... ] 

record [ field_spec , ... ] 
atomic_record [ field_spec , ... ] 

oneot [ field_spec , ... } 

variant | field_spec , «.. ] 

atomic_variant [ field_spec , ... 

proctype ( [ type_spec , = nbn ioe 
Itertype ( [ type_spec, .. -]) [yietds ] [ signais ] 
creatortype ( [ type_spec,, ... ] ) [ retume ] [ signais ] 
handiertype ( [ type_spec., ,.. ] ) [ retums ] [ signals ] 
mutex [ type_actual ] 

reference 


name , ... : type_actual 
idn 

idn [ actual_parm, ... ] 
reference $ name 


constant 
type_actual 


type_spec [ with { where opbinding , ... } ] 


com NAMe , wee : primary 


Syntax 
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expression 


primary 


call 


call @ primary 

( expression ) 

~ expression 

— expression 

expression ** expression 
expression // expression 
expression / expression 
expression * expression 
expression || expression 
expression + expression 
expression — expression 
expression < expression 
expression <= expression 
expression = expression 
expression >= expression 
expression > expression 
expression ~< expression 
expression ~<= expression 


primary . name 
Primary [ expression ] 


primary ( [ expression , ... ] ) 


%6& (precedence) 


KX KKK KKK KKK KK KK KX XK KX 2k 


6 


NNN NNN NN AN ND 
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entity = nil 
true 
false 
int_literal 
real_literal 
char literal 
string_literal 
self 
reference 


entity [ expression ] 

bind entity ( [ bind_arg, ... ] ) 

type_spec $ { field , ...} 

type_spec ${ [ expression : ] [ expression , ... ] ] 
type_spec $ name [ [ actual parm, ...] ] 

up ( expression ) 

down ( expression ) 


| 
| 
| 
| 
| 
| 
| 
| 
| entity « name 
| 
| 
| 
| 
| 
| 
| 


field :s= name, ..: expression 


bind_arg 4 — ay 
expression 
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Comment. a sequence of characters that begins with a percent sign (%), ends with a newline 
character, and contains only printing ASCII characters and horizontal tabs in between. 


Separator. a blank character (space, vertical tab, horizontal tab, carriage return, newline, form feed) or 
a comment. Zero or more separators may appear between any two tokens, except that at least one 
separator is required between any two adjacent non-self-terminating tokens: reserved words, identifiers, 
integer literals, and real literats. 


Reserved word. one of the identifiers appearing in bold face In the syntax. Upper and lower case 
letters are not distinguished in reserved words. 


Name, idn: a sequence of letters, digits, and underscores that begins with a letter or underscore, and 
that is not a reserved word. Upper and lower case letters are not distinguished in names and idns. 


int_literak. a sequence of one or more decimal digits (0-9) or a backslash (\) followed by any number of 
octal digits (0-7) or a backslash and a sharp sign (W) followed by any number of hexadecimal digits (0-9, 
A-F in upper or lower case). 


Real_literal: a mantissa with an (optional) exponent. A mantissa is either a sequence of one or more 
decimal digits, or two sequences (one of which may be empty) joined by a period. The mantissa must 
contain at least one digit. An exponent is 'E’ or 'e’, optionally followed by ‘+’ or ’-’, followed by one or 
more decimal digits. An exponen is required if the mantissa does not contain a period. 


Char__literat. a character representation other than single quote, enclosed in single quotes. A 
character representation is either a printing ASCH character (octal value 40 through 176) other than 
backslash, or an escape sequence consisting of a backslash (\) followed one to three printing characters 
as shown in Table 6-1 or Table I-1 below. 


String_Iiteral: a sequence of zero or more character representations other than double quote, enclosed 
in double quotes. 


Table I-1 shows most of the character literals supported by Argus, except for the higher numbered octal 
escape sequences. For each character, the corresponding octal Iteral, hexadecimal literal, and normal 
literal(s) are shown. Upper or lower case letters may be used in escape sequences of the form \#**, \’’, 
\r", \b, \t, \n, \Wv, \p, and \r. Note that an implementation need not support 256 characters, in which case 
only a subset of the Mterais listed will be legal. 
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Table +1: Character Escape Sequences 


Syntax 


000’ "00" 14@’ 
001" O01" \4A’ 


1007" #07" \“G' 


010" \#08" “\4H’ ib’ 


011° \o9’ VAP WW 


012’ WHOA’ WJ" An’ 
1013’ 0B’ 4K’ Vv’ 
1014’ HOC’ VAL’ Vp’ 
4015’ \H#OD’ VM" Vr’ 


016’ \4OE’ \4N’ 
1017’ OF’ 40" 


020’ \#10" \4P’ 
4021" "11" \4Q' 
O22’ W412’ VAR’ 
023’ "#13" 4S’ 
1024 Wi4' VT 
\025" 15" \4U" 
1026’ \#16' 1V 
1027" 17" \“W" 


030" 18" 14x’ 
031" W19 AY" 
N032" WIA" \Z’ 
033’ WB’ VY 
O34’ WIC! AV" 
035’ WID' Vy 
N036’ WIE” \4*" 
NOS7 WHF’ 


n041" 21" 'T 
1042" *w22" = \" 
1043" #23" '# 
N044' #24" '$' 
"045" "25" "%' 
1046" #26" '&’ 
\047" a7" 1" 


"050" #28" '( 
N051" #29") 
1053" W2B' *+' 
1054’ #20" ', 
N055" 2D" '-’ 
N057" W2F" ‘7 


\100' #40’ '@’ 
101" \#41" "A" 
102" \#42" 'B’ 
103’ \#43" ’C’ 
\104’ \#44' 'D’ 
\108’ "45" 'E’ 
\106' #46" 'F 
\107" \447" 'G’ 


1110" \#48" 'H’ 
\111" \aag’ *P 

4112" \A4A’ ‘J’ 
113" \#4B' ’K’ 
\114' \44C''L’ 
4115" \4D" 'M’ 
\116" \#4E’ ’N’ 
\117' \A4F’ 'O’ 


120° "W500" ’P” 
121" \#51' Q’ 
122" \#52’ ’R’ 
1123" \4S3' ’S’ 
124° \854' 'T 
125’ WS5" 'U’ 
126’ \aS6" 'V’ 
\127 VST 'W' 


1130" \#58" 'X’ 
1131" 59" 'Y’ 
1132" \ASA’ 'Z" 
\133' SB" T’ 
1134" AEC" NV 
1136" ‘WSD" T 
198" SE!" 
\37 WOR’ 


140" eo’ "’ 
\141' \#61"'a’ 
1142’ #62’ ’b’ 
\143' \463’ ’c’ 
\144" \#64’ 'd’ 
145" 65" 'e’ 
1146" W66' 'f’ 
\147' \467'" 'g’ 


150" #68" ’h’ 
1151" \W69' 7’ 
\152" \6A' |’ 
153’ 6B" ’k’ 
\154’ \WW6C’ 'T 
158’ \6D" 'm’ 
1156" "V46E’ ’n’ 
\157" \46F" ’o’ 


200° #80" 1k" 
1201’ \#61" VIA’ 
\202" \#62' \IB' 
4203’ #83’ “\IC’ 
\204' “\a84' ID" 
\205" es’ VIE’ 
1206" #86" “\IF" 
\207’ \#87" \IG’ 


210° #68" “\IH’ 
1211’ \wee' A 

\212' VBA’ WU’ 

1213’ \W6B’ \K 
\214' WeC’ Vi’ 
215’ \#6D" IM’ 
1216” "W8E’ “\IN’ 
1217 \HOF’ \10’ 


4220" "90" “\IP’ 
\221° wot" IC’ 
\222’ \#62" VIR’ 
\223' #93’ ‘IS’ 
\224' \#e4’ \IT 
\225' \#95" “\IU" 
\226" \#96" NIV" 
\227" W497" \IW" 


\230' woe’ UX" 
1231" woo’ IY’ 
1232" WOA' VIZ’ 
1233" WOB' I" 
A234" HOC" “\N' 
4236" #90" ‘I 
1296" WOE" "\H" 
A237 WOF AL" 


\240’ \#A0' V8.’ 
\241’ VAI’ \8P 
\242’ \HA2’ VA" 
1243’ WA’ V8.8" 
\244' \#A4' \8$' 
\245' VAS’ \&%’ 
1246" \#A6' V8.8’ 
\247' WAT 8" 


4250" WAG’ \8(’ 
1251’ WAO' 18)’ 
4252’ WAA' 8" 
A253’ \WAB' \k+’ 
A254’ \HAC’ 8,’ 
255’ AD’ \&-’ 
256" WAE’ 8.’ 
\257' WAP’ \8/ 


4300’ \#CO’ 2.@’ 
4301" C1’ 8A’ 
1302’ WC2’ \8B" 
1303’ C3’ VAC’ 
1304 C4’ VD’ 
A308’ "WCS’ VRE’ 
306" C6’ \&F” 
4307 'WC7’ \&G' 


\310° ‘C8 \4AH’ 
1311’ Co’ Var 

1312 \WCA’ Na’ 
1313’ WCB’ 2K’ 
1314 \8CC’ VAL’ 
1315" CD’ Vem’ 
1316 WCE’ \4N’ 
1317 WCF \&0' 


\320' “WwODO0’ \4P’ 
1321" D1" \éQ’ 
1322 D2" VAR’ 
4323" “WD3’ 4S’ 
324 \D4' VAT 
1325’ "#D6’ V4U" 
\326' "WO6' Va’ 
4327 \#D7' \aW’ 


A330" WDB" 18x’ 
1331’ \#09' 4" 
332" WDA’ \8Z" 
4333" OB’ Val" 
4334" WDC’ 148’ 
4335’ WOD’ a)’ 
A396" WDE’ Va" 
A337 WOF V4’ 


340’ ‘WEO’ Va” 
1341" WEI" Vea’ 
A342’ WE’ Veb’ 
A343’ WES’ Vac’ 
1344’ WEA’ Vad’ 
A345’ WES’ ke’ 
A346’ WEG’ Vat 
\B47 WET’ ag’ 


1350" WES’ VEh' 
1351" \WEQ’ Val’ 
1352" WEA’ \8/' 
\353' WEB’ Vek’ 
1354’ "WEC’ Nar’ 
355" ‘WED’ Nam’ 
1356’ WEE’ Van’ 
1357 WEF’ \&o’ 
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Appendix Il 
Built-in Types and Type Generators 
The following sections specify the built-in types and the types produced by the built-in type generators 
of Argus. For each type and for each instance of each type generator, the objects of the type are 
characterized, and all of the operations of the type are defined. (An implementation may provide 
additional operations on the built in types, as long as these are operations that could be implemented in 
terms of those described in this section.) 


All the built-in types (except for any) are transmissible. All instances of the built-in type generators 
(except for proctype and Kertype) are transmissible if all their type parameters are transmissible. 
Transmission of the built-in types preserves value equality, except for objects of type real. However, in a 
homogeneous environment, reals can be transmitted without approximations. in a homogeneous 
environment, the only possible encode or decode failures are exceeding the representation limits of an 
Image, mutating the size of an array or atomic_ array while it is being encoded or decoded, and 
improper decoding of cyclic objects (see Section 14.4). 


All operations are indivisible except at calls to subsidiary operations (such as Int$similar within 
artray[int]$similan, at yields, and while waiting for locks. 


The specifications given below are informal and are adapted from the book Abstraction and 
Specification in Program Development (Liskov, B. and Guttag, J., MIT Press, 1986). A specitication starts 
out by giving a list of the operations and declarations of any formal parameters for the type. This is 
followed by an overview, which gives an introduction to the type and if necessary defines a way of 
describing the type’s objects and their values. Following this the individual operations are described. For 
each operation there is a heading and a statement of the operation's effects. in the heading, the return 
values may be given names. The effects section describes the normal and exceptional behavior of ihe 
operation. The effects given are abstract, that is they are described using the vocabulary (or model) 
defined in the overview section. For example, objects of type int are described using mathematical 
integers. Thus arithmetic expressions and comparisons used in defining Int operations are to be 
computed over the domain of mathematical integers. 


An operation that (abstractly) mutates one of its arguments lisis the arguments that it mutates in the 
clause following the word modifies. An operation is not allowed to mutate any objects, except for those 
listed in the modifies clause. (For the built-in mutable atomic type generators, modification only refers to 
the sequential state; it does not refer to changes in the locking information kept for each object.) When 
an argumem, say a, is mutated, it Is often necessary to describe its state at the start of the call as well as 
its final state at the end of the call. We use the notation a,,, for a's state at the start of the call and the 
notation 4,,,., for its state at the end of the call. 


Some operations of the buit in type generators are only defined # the type generator is passed 
appropriate actual routine parameters (see Section 12.6). For example, the copy operation of the array 
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type generator, is only defined #f there is an actual parameter passed (explicitly or implicitly) for the type 
parameter'’s copy operation. Thus array[int}$copy is defined but arraylany]$copy is not defined. These 
requirements are stated in a requires clause that precedes the description of the operation's effect. The 
type of the expected routine is also described; remember that the actual operation parameter can have 
fewer signals (see Section 6.1 and Section 12.6). 


By convention, the order in which exceptions are listed in the operation type is the order in which the 
various conditions are checked. 


Operations with the same semantics (for example, null$equa/ and nuil$similay) or that can be 
described in the same way (for example, Int$add and int$sub) are grouped together to save space. 


In defining the built-in types, we do not depend on users satistying any constraints beyond those that 
can be type-checked. This decision leads to more complicated specifications. For example, the behavior 
of the efements iterator for arrays is defined even when the loop modifies the array. 


li.1. Null 
null = data type is copy, equal, similar, transmit 
Overview 


The type null has exactly one, immutable, atomic object, represented by the itera! nil. Nil is 
generally used as a place holder in type definitions using oneofs or variants. 


Operations 


6qual = proc (n1, n2: null) returns (boo!) 
similar = proc (n1, n2: null) returns (bool) 
effects Returns true. 


copy = proc (n: null) returns (null) 
transmit = proc (n: null) returns (null) 
effects Returns nil. 


li.2. Nodes 
node = data type is here, copy, equal, similar, transmit 
Overview 


Objects of type node are immutabie and atomic, and stand for physical nodes. implementations 
should provide some mechanism for translating a node “address” into a node object and vice 
versa. (However, these do not have to be operations of type node.) 


Operations 


here = proc () returns (node) 
effects Returns the node object for the caller's node. 


equal = proc (n1, n2: node) returns (boo!) 
similar = proc (n1, n2: node) returns (boo!) 
effects Returns true if and only if n1 and n2 are the same node. 
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Copy = prac (n: nods} seme (nade) 
eRecte Rekuwna n. 


1.3. Booleans 
bool = dete type te and, or, not, equal, similar, copy, tmanenit 
Overview 


The two immutable, atomic objects of type boot, with ferns fue and falee, represent logical truth 


The language sise provides the operators ennd end eer tor conditions! evaluation of boolean 
expressions, see Gection 9.15. 


Operations 
and = prec (b1, 62: Beet retame aed 
otletts Returns wue E &1 and if are beth true; reams tains othervice. 


Operations 
add = proc {x, y: 


tnt) rote (in 
cub ~ pone fx. y: tnt} 
rad = pan bx, ¥ 


from _to = Ber feem, youbin Gt) 
caaate Poo chose eaetadlte bem, ® ) byttram, fo, 1). 


max = ; ems 
Gres va tee eaten uhansiiawbinis 3 


Min = PROG (x, y: feat 
enact, enone orn ar 


Emenee the carne ntager; rehane (olen otherwise. 


Copy = proc (x: but} esterne (int) 
ottects Returns x. 
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transmit = proc (x: int) retume (y: Int) signete(faiure(string)) 
effects Retums y such that x = y or signals failure if x cannot be represented in the 
implemeniation on the receiving end. 


11.5. Reals 


real = data type is add, sub, minus, mul, div, power, abe, max, min, exponent, mantissa, i2r, r2i, 
trunc, parse, unparse, kh, le, ge, gt, equal, similar, copy, transmit 


Overview 


The type real models a subset of the mathematical numbers. is used for approximate or floating 
point arithmetic. Reals are immutable and atomic, and are written as a mantissa with an optional 
exponent. See Appendix | for the format of real iterals. 


Each implementation represents a subset of the real numbers in: 
D = {-real_max, —real_min} U {0} U {real_min, real_max} 
where 
0 < real_min < 1 < real_max 
Numbers in D are approximated by the implementation with a precision of p decimal digits such 


that: 
Vre D Approx(r) « Real 
Vre Real Approx(r) =r 
vre D— {0} | (Approx(r) — rr] < 101? 
vrseD <8 => Approx(r) < Approx(s) 
Vre D Approx(—r) = ~Approx(r) 


We define Max_width and Exp_width to be the smallest integers such that every nonzero element 
of real can be represented in “standard” form (exactly one digit, not zero, before the decimal 
point) with no more than Max_ width digits of mantissa and no more than Exp width digits of 
exponent. 


Real operations signal an exception if the resuk of a computation lies outside of D; overfiow 
occurs if the magnitude exceeds rea/_max, and underfiow occurs if the magnitude is less than 
real_min. 


Operations 


add = proc (x, y: real) returns (real) signais (overflow, underflow) 
effects Computes the sum z of x and y; signals overflow or underfiow if z is outside of D, as 
explained earlier. Otherwise returns an approximation such that: 
(xy 2 0 v x,y S 0) => add(x, y) = Approx(x + y) 
add(x, y) = (1 + €)(x + y) lel < 10°? 
add(x, 0) = x 
add(x, y) = add(y, x) 
x <x’ => add{x, y) < add(x’, y) 
Sub = proc (x, y: reel) returns (real) signals (overfiow, underflow) 
effects Computes x — y; the result is identical to add(x, —y). 
minus = proc (x: real) returns (real) 
effects Returns —x. 
mul = proc (x, y: real) returns (real) signals (overfiow, undertiow) 
effects Returns approx(xy); signals overflow or underflow Hf xy is outside of D. 
div = proc (x, ye VE Uae a ee On divide, overflow, underflow) 


0, signals zero_ divide. Otherwise returns approx(x/y); signals overfiow or 
gaven tie wyis outside of D. 
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power = proc (x, y: real) returns (real) 
signals (zero_divide, complex_resutt, overflow, underflow) 
ae hz = oy < 0. signals zero__ “divide. Wx < 0 and y is nonintegral, signals 
complex _result. Otherwiee returns an approximation to 2’, good to p significant digits; 
signals overfiow or underflow if x” is outside of D. 


abs = proc (x: real) returne (reel) 
criechs Ratnvic the abesune vase OF. 


max = proc (x, y: real) returns (real) 
effects If x2 y, then returns x, otherwise returns y. 


min = proc (x, y: real) returns (real) 
effects if x < y, then returns x, otherwise retume y. 


exponent = proc (x: reel) returns (int) signals (undefined) 
effects if x = 0, signals undefined. Otherwiee returns the exponent that would be used in 
representing x as a literal in standard form, that is, returns 
max ({I | abe(x) 2 10/}) 


mantissa = proc (x: real) returns (real) 
effects Retums the mantissa of x when represented in standard form, that is, returns 
approx(x/10°), where e = exponenti(x). it x = 0.0, returns 0.0. 


i2r = proc (i: int) returns (real) signals (overflow) 
effects Returns approx()); signals overfiow it /is not in D. 


r2i = proc (x: real) returns (Int) signals (overflow) 
effects Rounds x to the nearest integer and toward zero in case of a tie. Signals overfiow if 
the result ies outside the represented range of integers. 


tune = pros te real) returns (int) signals (overfiow) 
effects Truncates x toward zero; signals overflow i the result would be outside the 
represented range of integers. 


salar vod a er ae otes ak eae , undertiow) 
Retr ago), eva ptnurns by te rg # (00 Azan. 
must represent a real or integer eral wih an optional leading plus or minus sign; 
sth eteée tials ad. Wntat Signals underflow or overflow lf 2 ie not in D. 


unparse = proc (x: real) returns (string) 
effects Returns a real Meral such that parse(unparse(x)) = x. The general form of the literal 


[-] /fletat_feia[ + x_feid] 
Leading zeros in /_ fleid and trailing zeros in f_field are suppressed. lf x is integral and 


the itera! is in standard form, with Exp_width digits of exponent. 


it = proc (x, y: real) returns (bool) 
fe = proc (x, y: real) returns (boo!) 
ge = proc (x, y: real) returns (boo!) 
gt = proc (x, y: real) returns (boo!) 
effects These are the standard ordering relations. 


equal = proc (x, y: real) returns (bool) 
similar = proc (x, y: real) returms (boo!) 
effects Returns true if x and y are the same number; returns false otherwise. 


1.6. Characters 
cher = dete type te i2c, c2i, R, le, ge, gt, equal, siullar, cnpy, tema 


. “ ; 5 signa Magel_char' x ig nat in the range 


se <7 -— RR  E 
| character). 
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li.7. Strings 


string = data type is c2s, concat, append, substr, rest, size, empty, fetch, chars, indexs, indexc, 
82aC, aC28, $28C, SC2s, Kt, le, ge, gt, equal, similar, copy, transmit 


Overview 


Type string is used for representing text. A string is an immutable and atomic tuple of zero or 
more characters. The characters of a string are indexed sequentially starting from one. Strings 
are lexicographically ordered based on the ordering for characters. 


A sting eral ie writen a8 8 sequence of zero or more character representations enciosed in 


C2s = proc (c: char) returns (string) 
effects Retums a string containing cas is only character. 


concat = proc ($1, ee ee ee ee 
effects Returns the concatenation of s7 and 22. That ie, rhe goed an index of $7 and 
{(slze(s1)+4us4i for | an index of s2. Signals Amite f r would be too large for the 
implementation. 


append = proc (s: string, c: char) returns (r: string) signals (limits) 
effects Returns a new string having the characters of s in order followed by c. That is, 
Asize(s)+1] = c. Signals limits if the new string would be too large for the implementation. 


substr = proc (s: rolls pg Sronscurigtlalbpaghled ade bys gral ierylgoeiliy ark oon 
effects If cnt < 0, signais negative_size. Mela Safdar , Signals bounds. 

Otherwise retums a string having the characters s{af, alat+1), .. 7 hacer the new 
String contains min(cnt, size~at+1) characters. For exampie, 

substr ("abcdef”, 2, 3) = "bed" 

substr ("abcdef", 2, 7) = "bcdef” 

substr ("abcdef", 7, 1) =" 
Note that if min(cnt, size-at+1) = 0, subsir retums the empty string. 


rest = proc (s: string, i: Int) returns (r: string) signaie (bounds) 
effects bounds it i < 0 or / > size(s) + 1; otherwise retums a string whose first 
character is s{/, whose second is a/+1], ..., and whose size(rth character is s{size(s)). 

Note that # / = size(s)+1, rest retumns the empty string. 


size = ss ahaethe String) returns (int) 
effects Returns the number of characters in s. 


empty = proc (s: string) returns (bool) 
effects Returns true if s is empty (contains no characters); otherwise retums false. 


fetch = proc (s: string, i: int) returns (char) signals (bounds) 

effects Signals bounds if i < 0 or i> size(s); otherwise returns the ah character of s. 
chars = Iter (s: string) ylekis (char) 

effects Yiekdis, in order, each character of s (i.e., s[1], s{2], ...). 
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indexs = proc (s1, s2: string) returne (int) 
effects if s1 occurs as a substring in s2, returns the least index at which s? occurs. Returns 
0 if 57 does not occur in 82, and 1 if $1 is the empty string. For example, 
indexs("abc", "abcbc") = 1 
indexa(“be", “abche") = 2 
indexs("", “abode") = 1 
indexs("beb”, “abcde") = 0 


indexc = proc (c: char, s: string) returns (int) 
eftects if c occurs in s, retums the least index at which c occurs; returns 0 # c does not 
occur in s. 


s2ac = proc (s: Pesala es returns (array{char]) — 
effects Stores the characters of s as elements of a new array of characters, a. The low 
bound of the array is 1, the size is size(s), and the &h element of the array is the th 
character of s, for 1 < i < size(s). 


ac2s = proc (a: asreyichee? returme (string) 
effects This is the inverse of s2ac. The resutt is a string with characters in the same order 
ome That the ah character of the string is the (/-array(char}$/ow(a)—-1)th element 
a. 


S2sc = proc (s: string) returns (sequence[char)) 
effects Transforms a string into a sequence of characters. The size of the sequence is 
sizes). The th element of the sequence Is the &h character of s, for 1 < i< sizes). 


SC2s = proc (s: sequence[char)) returns (string) 
effects This is the inverse of s2s8c. The result le a string with characters in the same order 
as ins. That is, the Ah character of the string is the th element of s. 


= proc (81, 82: string) returns (bool) 
ipa proc (e1-co: stim) seturie (bash 
ge = proc (s1, 62: string) returns (bool) 
gt = proc (81, s2: string) returns (boo!) 
effects These are the usual lexicographic ordering relations on strings, based on the 


equal = proc (81, S2: string) returns (bool) 
salar etc 82: string) returne (bool) 
effects Returns true ff s1 and s2 are the same string; otherwise retums false. 


Copy = proc (81: nels gaan (string) 
effects Retums 


transmit = proc (s1: string) returns (string) signals (failure(string)) 
effects Returns s1. Signals faiure only i $1 is not representable on the receiving end. 
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11.8. Sequences 


sequence = data type |t: type] Is new, e2s, fill, fill_ copy, replace, addh, addi, remh, rem!, concat, 
subseq, size, empty, fetch, bottom, top, elements, indexes, a2s, s2a, 
equal, similar, copy, transmit 


Overview 


Sequences represent immutable tuples of objects of type t. The elements of the sequence can be 
indexed sequentially from 1 up to the size of the sequence. A&hough a sequence is immutable, 
the elements of the sequence can be mutable objects. The state of such mutable elements may 
change; thus, a sequence object is atomic only if its elements are aleo atomic. 


Sequences can be created by calling sequence operations and by means of the sequence 
constructor, see Section 6.2.8. 


Any operation cail that attempts to access a sequence with an index that is not within the defined 
range terminates with the bounds exception. The size of a sequence can be no larger than the 
largest positive Int (int_max), but an implementation may restrict sequences to a smaller upper 
bound. De sitafigt to conainucta sequence utich ia tec laces fesvhe #7 a fale encertor. 


Operations 


Pawn Dros () tetutns (eemverent 
effects Returns the empty sequence. 


62s = proc (elem: t) returne (sequenceit]) 
effects Returns a one-elernent having elem as its only element. 


fill = proce (cnt: int, elem: t) returns (sequenceit}) signals (negative_size, limits) 
effects If cnt < 0, signals negative_size. ord fe rant SON ie, memsirnin eoaerics Sze 
supported by the implementation, signals Mnits. Otherwise returns a sequence having 
cnt elements each of which is efem. 


fill_copy = proc (cnt: int, elem: t) returns (sequenceit}) 
signais (negative_size, limits, failure(string)) 

io tegetelagf cep eicg  ge grei h 

effects If cnt < 0, signals negative__size. i cnt is bigger than the maximum size of 
sequences that the implementation supports, signals sits. Cine eth shew 
sequence having cnt elements each of which is a copy of elem, as made by copy. Note 
that S$copy is called cnt times. Any failure signal raised by Scopy is immediately 
resignalied. This operation does not originate any fafure signals by itself. 


replace = proc (8: sequenceit], |: Int, elem: t) returns (sequenceft]) signals (bounds) 
effects If i< 1 or i> high(s), signals bounds. Otherwise retums a sequence with the same 
elements as s, except that efem is in the &h position. For example, 


replace(sequence[int}$[2,5], 1, 6) = sequencefint}$i6, 5] 


addh = proc (s: sequencelt], elem: t) nega Sate gsr sag 
effects Returns a sequence with the same elements as s followed by one additional 
element, elem. That is, i el il ao eal rein alt oye 

sequence would be larger than the implementation supports, signals #mits 


add! = proc (s: sequenceft], elem: t) returne (r: sequenceft}) signals (limits). 
effects Returns a sequence having elem as the first element followed by the elements of s 
in order. That is, {1}-elem and qj~a{i-1] for j= 2, ..., size(r). the resulting sequence 


would be larger than the implementation supports, signals fits. 
remh = proc (s: sequenceit}) returns (r: Soh, oe oe 
effects If s is empty, signals bounds. Otherwise a sequence having ail elements of s 


in order, except the last one. That is, planed iesasnge and A4=94 for i= 1, ..., size(s}-1. 


of sh onder, cusegl tee tral one. wee § nie li ies i= 
concat = proc (st, er . 
sHeste Reasee ihe 


sears =e: Seguanend va 
ake ee ee a 


is elements of a ix the same onder as in a. 


82a = Gros (2: SORNROORE BukueNE GerMEYRE 
otters Pertaene 6 ee sonny Ate ale Salen 1 Gnd tening the etommonts a © in the samme 
onder on ina. 


cquel = prac (s1, of: enquanaegy 


paited ny Requal. The effect of 
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copy = proc (s: sequenceit]}) returns (sequenceit]) signals (faiure(string)) 
requires thas copy: s-video pay ea 
effects Retums a sequence having as elements copies of the elements of s. The effect is 


Soe @: t in vv ee do 
@Saddiny, tScopy(e)) resignal failure 


retum (y) 
transmit = proc (s: sequenceit]) returns (sequenceit]) signals (failure(string)) 
requires thas tranemk 


effects Retums a sequence having as elements transmitted copies of the elements of s in 
the same order. Sharing among elements is preserved. Signais failure if this cannot be 
represented on the receiving end and also resignais any failures from Stranemit. 


11.9. Arrays 


array = data type [t: type] Is create, new, predict, fill, fil_ copy, addh, addi, remh, remi, 
set_low, trim, store, fetch, bottom, top, empty, size, low, high, elements, indexes, 
equal, similar, similar1, copy, copy1, transmit 


Overview 


Arrays are mutable objects that represent tuples of elements of type f that can grow and shrink 
dynamically. Each array's state consists of this tuple of elements and a low bound (or index). The 
elements are indexed sequentially, starting from the low bound. Each array also has an identity 
as an object. 


Arrays can be created by calling array operations create, new, fill, fill_copy, and predict. They can 
also be created by means of the array constructor, which specifies the array low bound, and an 
arbitrary number of initial elements, see Section 6.2.9. 


Operations low, high, and size return the current low and high bounds and size of the array. For 
array a, size{a) is the number of elements in a, which is zero f ais empty. These are related by 
the equation: high(a) = low(a) + size(a) — 1. 


For any index / between the low and high bound of an array, there is a defined element, aff. The 
bounds exception is raised when an attempt is made to access an element outside the defined 
range. Any array must have a low bound, a high bound, and a size which are ail legal integers. 
An implementation may restrict these to some smaiier range of integers. A cali that would lead to 
a a acd 
exception. 


Operations 
create = proc (Ib: int) returns (arrayj(t]}) signals (limits) 
effects Returns a new, empty array with low bound /b. Limits occurs if the resulting array 
would not be supported by the implementation. 


new = proc () returns (array(t]) 
effects Returns a new, empty array with low bound 1. Equivalent to create(1). 


ps 


oc = peas (a: Seg some § agate Gan 
aeveg hl, seme: § agate Penta) 
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store = proc (a: array{t], i: Int, elem: t) signals (bounds) 
modifies a 


etfects i < fow{a) or /> high, signals bounds; otherwise makes elem the element of a 
with index i. 


fetch = proc (a: arrayjt], i: Int) returns (t) signals (bounds) 
effects If i < lowa) or i > highta), signals bounds; otherwise returns the element of a with 


index i. 
bottom = proc (a: arrayjt]) returns ata signals (bounds) 
effects If ais empty, signals bounds; otherwiee returns a[low(a)]. 


top = proc (a: array[t]) returns (t) signals (bounds) 
effects if ais empty, signals bounds; otherwise returns a higtia)]. 


ompy 5c oe eee 
Returns true if a contains no elements; otherwise retums false. 


size = proc (a: afray[t]) returns (int) 
etfects Retums a count of the number of elements of a. 


low = proc (a: array/t}]) returns (int) 
effects Returns the low bound of a. 


high = proc (a: :erray{t) retume (int) 
effects Returns the high bound of a. 


elements = Ker (a: array[t]) yleids (t) signais (failure(string)) 
effects Yields the elements of a, exactly once for each index, from the low bound to the high 
bound (/.€., DOMOM A»), ..., 10P(Bypq)). The elements are fetched one at a time, using 
the indexes that were legal at the start of the call. 4, during the Keration, a is modified so 
that fetching at a previously legal index signals bounds, then the iterator signals failure 
with the string "bounds". The Kerator is divisible at ylelds. 


indexes = Iter (a: array[t]) ylekis (Int) 
effects 


Yields the indexes of a from the low bound of 4,,. to the high bound of . Note 
that indexes is unaffected by any modifications done by the loop body. It is divisible at 
yields. 


equal = proc (a1, a2: arrayjt]) returns (bool) 
effects Returns true ff a7 and a2 refer to the same array object; otherwise returns false. 


similar = proc (a1, a2: array[t]) returns (bool) signals (falure(string)) 
requires thas similar: proctype (t, t) returne (bool) signaie (failure(string)) 
effects Returns true if a7 and a2 have the same low and high bounds and if thelr elements 
are pairwise similar as determined by Ssimilar. This effect of this operation ie equivalent 
ee ee rer ren crate pte eee 
at = array/t] 
pen rm ~m at$iow(a2) cor at$size(a1) ~= at$size(a2) 
then return (false) 


for i: rary In at$indexes(a1) do 
H ~t$similar(a[i], a2/i]) then return (false) end 
resignal failure 


except when bounds: signal failure("bounds”) end 


end 
return (true) 
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similar! = proc (a1, a2: arrayjt]) returns (bool) signals (faiure(string)) 
requires thas equal: proctype (t, t) retums (beo!) signals Ar atebarta 


equal 
similar, except that Requal is used instead of Seiniar. 


copy = proc (a: prided Abaerainc (b: array[t]) signals (fallure(string)) 
requires f posal gras Meare en nsigued aio asia 
effects Returns a new array b with the same low and high bounds as a and such that each 
elemem bf contains Scopyaf). The effect of this operation is equivalent to the 
ee et een ere 
(a) 


om arrayfifeoopy1 
‘ce i: int In arrayft}$indexes(a) do 
bfi] := t$copy(afi}) 
resignal failure 
except when bounds: signal failure("bounds") end 
end 
return (b) 


copy1 oe atray(t) returns (b: arrayjt]) 
effects Returns a new array b with the same low and high bounds as a and such that each 
element b[4 contains the same element as af. 


transmit = proc (a: arrayj{t]) returns (b: atrayjt]) signals (failure(string)) 
requires thas tranemit 
effects Returns a new array b with the same low and high bounds as a and such that each 
element O[4 containe a transmitted copy of aff. Sharing among the elements of a is 
preserved in b. Signals failure if b cannot be represented on the receiving end or if 
fetching an element at a legal index of 4,,. causes a bounds exception and resignais any 
failure signals raised by Stranemk. 


1.10. Atomic Arrays 


atomic_array = data type jt: type] is create, new, predict, fill, fil copy, addh, addi, remh, remi, 
set_low, trim, store, low 


Overview 


Atomic_ arrays are mutable atomic objects that represert tuples of elements of type f that can 
grow and shrink dynamically. Each atomic_array's (sequential) state consists of this tuple of 
elements and a low bound (or index). The elements are indexed sequentially, starting from the 
low bound. Each atomic_array also has an identity as an object. 


Atomic_arrays can be created by calling atomic_array operations create, new, fill, fill_ copy, and 
predict. They can also be created by means of the atomic_array constructor, which specifies the 
array low bound, and an arbitrary number of initial elements, see Section 6.2.9. 


Operations low, high, and size retum the current low and high bounds and size of the 
atomic_array. For an atomic_array a, size(a) is the number of elements in a, which is zero if ais 
empty. These are related by the equation: high(a) = = low a) + size(a) — 1. 
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noe) vi gree BRR ER AS SEE AS EE a RES eae eR eee 


: implementation may 
that would lead to an atomic_array whose low or high bound or size is outside the defined range 
terminates with a limits exception. mits exception. 


Atomic_ arrays use read/write locking to achieve atomicity. The locking rules are described in 
Section 2.2.2. It is an error f a process that is not in an action attempts to test or obtain a lock; 
when this happens the guardian running the process will crash. As defined below, the only 

ion. 


operation that (in the normal case) does not attempt to test or obtain a lock is the equa! operat! 


Operations 


create = proc (Ib: int) returns (a:atomic_array(t]) signais (limits) 
ettects Retums a new, empty atomic_ array a with low bound 6. Limits occurs # the 


new = proc () returns (atomic_array(t]) 
effects Equivalent to create(1). 


predict = proc (ib, cnt: int) returne (a: atomic_array(t) signals (limits 


f 
: 
3 
i 
t 
i 
i 


fill = proc (Ib, cmt: Int, elem: t) returns (atomic _arrayft]) signels (negative_size, limits) 
effects if cnt < 0, signals negative_size. Returns a new atomic_array with low bound © and 
size cnt, and with elem as each element; if this new atemic_array would net be supported 
by the implementation, signals mits. The caller obtains a read lock on the result. 


fill_copy = proc (Ib, cnt: int, elem: t) returns (atomic | 
signals ( 


addh = proc (a: atomic_arrayjt], elem: t) signats (limits) 
modifies 


a. 
effects Obtains a write lock on a. if extending a on the high end would cause the high 
bound or size of a to be outside the range supported by the knplementation, then signals 
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addi = proc (a: atomic_arrayjt], elem: t) signals (limits) 
modifies a. 


ettects Obtains a write lock on a. If extending aon the low end would causes the low bound 
Oe ce ees ee eee ee then signals simits. 
Otherwise extends a by 1 in the low disaction, ard stores efem as the new element. That 


18, Baogd OW Ayyg)—1] = olor. 
Pn eee eee ereree Orne enerene comer, 
stiacie: Cuniiva 6 wiki We on & Hf a is empty, signals bounds. Otherwise shrinks a by 
removing its high elemen, and retums the removed element. That is, WGN Acq) = 
high( aq) ~ 1. 


remi = proc (a: atomic _arrayjt]) returns (t) signale (bounde) 
modifies a. 


effects Obtains a write lock on a. if a is empty, signals bounds. Otherwise siwinks a by 
removing its low element, and returns the removed elemert. That is, low( a.) = 


lOw( aap) + 1. 
set_low = proc (a: atomic_arrayjt], lb: int) signals (limits) 
modifies a. 


effects Obtains a write lock on a. if the new low (or high) bound would not php ay cetaorass 
the implementation, then signals imite. Otherwise, modillies the low and high bounds of 
a, the new low bound of a is & and the new high bound is /ipfa,,,) = 
HIGH Bypq)+10-1OWM B79). 
trim = proc (a: atomic_arrayjt], ib, cnt: int) signals (negative_ size, bounds) 
modifies a. 


effects If cnt < 0, signals negative_size and does not obtain any locks. Otherwise obtains 
write look on a. if >< jow(a) or b> high(a)+1, signals bounds. Otherwise, modifies a by 
a ee ee ee rec 
bound is ©. For example, f a= shemic_erveyfini{ilt 2,3,4,5), then: 
trim(a, 2, 2) reauils in a having value atemie_euay(intiSi2: 2, 3] 
trim(a, 4, 3) requite in a having value stowsle_erreyfint}${4: 4, 5] 


store = proc (a: stomic_arrayft], |: int, elem: t) signale (bounds) 
modifies a. 


effects Obtains a write lock on a. if / < jow(a) or / > highta), signals bounds; otherwise 
makes efem the element of a with index /. 


fetch = proc (a: stomic_arrayjtj, |: int) returne (t) signale (bounds) 
effects t /< low(a) oF |> hight), signels bounds bounds; othereise retums the element of a with 
index i. Always obtains a read lock on a. 


pen eS ee an a 
eae ; Otherwise retume adiow(a)]. Always obtains a read 
On 2. 


top = proc (a: atomic_array[t]) returne (t) signaie (bounds) 
eters Fas oney signals bounds; otherwise returns ajiigfia)]. Always obtains a read 
ona 


empty = Se ee ee 
effects Retums true ¥ a contains no elements, returns feiee otherwise. in either case 
obtains a read lock on a. 


eee ee momic_array{t]) returne (int) 
effects Retums a count of the number of elements of a, obtains a read lock on a. 
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low = proc (a: atomic_array[t]) returns (int) 
effects Returns the low bound of a, obtains a read lock on a 


high = proc (a: atomic_arrayjt]) returns (int) 
effects Returns the high bound of a, obtains a read lock on a. 


elements = Ker (a: atomic pad gh pad fs ed fares 
effects Obtains a read lock on a and yields the elements of a, each exactly once for each 
index, from the low bound to the high bound (1.¢., bofom(a,,,), .... '00(4,,,)). The 
elements are fetched one at a time, using the indexes that were legal at the start of the 
call. if, during the Keration, a is modified so that fetching at a previously legal index 
signals bounds, then the iterator signals faiure with the string “bounds”. The erator is 
divisible at yields. 


indexes = Iter (a: atomic_array(t]) yields (int) 
effects Obtains a read lock on a, then yields the indexes of a from the low bound of 
the high bound of 4,,.. Note that indexes is unaffected by any modifications done by the 
loop body. It is divisible at yields. 


a atomic_array[t]) returns (array{t]) 
effects Obtains a read lock on aa and returns an array a with the same (sequential) state. 


a2aa = proc (afray[t]) returns (aa: atomic_arrayft]) 
effects Returns an atomic_array aa wih the same state as a. Obtains a read lock on aa. 


equal = proc (a1, a2: atomic_arrayft]) returns (bool) 
effects Returns true if a! and a2 refer to the same atomic_array objeci; otherwise returns 
false. No locks are obtained. 


similar = proc (a1, a2: atomic_arrayft]) returne (boo! signals (failure(string)) 
requires thas similar: proctype (1, t) returne (bool) signals (fallure(string)) 
Oe ee ee ee ee 
are pairwise similar as determined by i§e#niar. See the description of the similar 
epsralion et ating 40¢ an Gaiinvahars btely a Gada. Thie operation is divisible at calis to 
SS$similar. Read locks are obtained on a1 and a2, in that order. 


similar! = proc (a1, a2: atomic_arrayjt]) returns (bool) signals (tallure(string)) 
requires {has equal: proctype (t, t) returns (beol) signals (failure(string)) 


copy = proc (a: atomic_array{t]) returns (b: atomic _arrayft]) signele (failure(string)) 
peng proctype () returns () signals (iure(string) 


thal can alactera Hl Covuaie Wo ib. See the desoription of the copy n of 
array for an equivalent body of code. This operation is divisible at calis to copy, and 
obtains read locks on a and b. 


Sey ee atomic gs Aigphiael flaar ip Oph y| 
effects Retums a new atomic_array b with the same low and high bounds as a and such 
thet each slomert £(f contains the sate siement ax aif Read locks are obtained on a 
and b. 
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transmit = proc (a: atomic_artayjt]) returns (b: atomic_arrayjt]) signals (failure(string)) 
requires thas tranemit 
effects Returns a new array b with the same tow and high bounds as a and such that each 
eiemem {4 contains a transmitted copy of a4. Read locks are obtained on a and b. 
Sharing among the elements of a is preserved in b. Signals failure if b cannot be 
represented on the receiving end or if fetching an element at a legal index of a,,, causes 
a bounds exception and resignais any failure signais raised by Stranemt. 


test_and_read = proc (aa: atomic_arrayjt]) returns (bool) 
effects Tries to obtain a read lock on aa. if the lock is obtained, returns true; otherwise no 
lock is obtained and the operation returns falee. The operation does not "wait" for a lock. 
Even the executing action “knows” that a lock could be obtained, falee may be 
returned. Even i false is returned, a subsequent attempt to obtain a read lock might 
succeed without waiting. 


test_and_write = proc (aa: atomic_arrayjt]) returns (bool) 
effects Tries to obtain a write lock on aa. if the lock is obtained, returns true; otherwise no 
lock is obtained and the operation returns false. The operation does not “wak” for a lock. 
Even if the executing action "knows" that a lock could be obtained, falee may be 
returned. Even if falee is returned, a subsequent atternpt to obtain a write lock might 
succeed without waiting. 


can_read = proc (aa: atomic_array[t]) returns (bool) 
effects 


lock could be obtained, false may be returned. Since some concurrent action may obtain 
or release a lock on an atomic_array at any time, the information returned is unreliable: 
even # true is retumed, a subsequent aitempt to obtain the lock may require waiting; and 
ican ne ere ee succeed 


can_write = proc (aa: atomic_array[t]) returns (bool) 
effects Returns true if a write lock could be obtained on aa without waiting, otherwise 


even if false is retumed, @ subsequent atiempt to obtain a write lock might succeed 
without waiting. 


read_lock = proc (aa: atomic_arrayjt]) 
effects Obtains a read iockon aa. . 


write_lock = proc (aa: atomic_array(t]) 
effects Obtains a write lock on aa. 
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let sch Des 82: st) returns (bool) signais (failure(string)) 
requires ch t ras Oxvhar plociyiee (1p atures (heen signals (ohuisiatiing) 
effects Returns true if s1 and s2 contain similar objects for each component as determined 
by the {$sinilar operations. Any failure signal is immediately resignaiied. This operation 
does not itself originate any faijiure signal. The comparison is done in lexicographic order 
of the selectors; if any comparison retume faise, falee is returned immediately. 


copy = proc (s: st) returns (st) eignale (failure(string)) 
requires each tf, has copy: proctype (i) returns (t) signals (failure(string)) 
effects Retums a struct containing a copy of each component of s; copies are obtained by 
calling the tScopy operations. Any failure signal is immediately resignaiied. This 
operation does not itself originate any failure signal. Copying is done in lexicographic 
order of the selectors. 


transmit = proc (s: st) returns (st) signals (failure(string)) 
requires each {has transmit 
ettects Returns a struct containing a transmitted copy of each component of s. Sharing is 
preserved among the components of s. Any failure signal from {¢Stranemit is 
immediately resignaiied. This operation does not tself originate any faffure signal. 


11.12. Records 
record = data type [n,:t,, ...,n,: t,] ler gets r, r_gets_s, set_ny,, ..., set_n,, get_n,,..., get_n, 
equal,similar, similar1, copy, copy1, tranemk 
Overview 
Boa ee ek ce ee een The names are called selectors, 
and the objects are called components. Different components may have different types. A record 
also has an identity as an object. 


An instantiation of record has the form: 
record | field_spec , ... } 
where 


Fr ete Ti Salechoie ft Ge iki wai’ GA ipubanmenice’ | (ignoring capitalization), but the 
a ee ee ree For example, the following name the same 


record|last, first, middie: string, age: int] 
record[last: string, age: int, first, middie: string] 


A record is created using a record constructor, see Section 6.2.11. 
For purposes of the certain operations, the the names of the selectors are ordered 
lex ly. Lipiioopraphie ordering 6F the selecince is Wee alphebatlo ordering of the-eelecor 
names written in lower case (based on the ASCII ordering of characters). 
In the following definitions of record operations, let rt = record[n,:t,, ..., n,: t,]. 
Operations 
r_gets_r= proc (r1, r2: rt) 
modifies r1. 
effects Sets each component of r1 to be the corresponding component of 2. 
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r gets | ote ond tt, 8: st) 
crn re acct re whos compara haf same scr nd ype a 
Sets each componert of rio be the: oe. 
set_n, = proc (r. rt, @: t) 
modifies r. 
etlecte Medilies r by mating the componert whose seledior is 7, be e. There is a set_ 
operation for each selector. 
sapien spar J 
effects Retums the component of rwhose selector is A, There is a get_ operation for each 
selector. 
equal = proc (rt, 12: rt) retume (eo!) 
effects Retume true # 11 andr? ave the samme record object; otherwise retume falas. 


Copy! = pres (7: 1) eohumne <t) 
etfecte Raturres a new record containing the components of r as a components. 
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11.13. Atomic Records 


atomic_record = data type [n, :t,, .... n,: t,] Is ar_gets_ar, set_ny,, ..., set_n,, get_n,, ..., get_n, 
ar2r, rar, equal,cimilar, simiari, copy, copy1, tranemit, 
test_and_read, test_and_write, can_read, can_write, read_lock, write_lock 


Overview 


An atomic_record is a mutable atomic collection of one or more named objects. The names are 
called selectors, and the objects are called components. Differem components may have different 
types. An atomic_record also has an identity as an object. 


An instantiation of atomic_record has the form: 

atomic_record [ field_spec , ...] 
where 

fieid_spec 5: name, ... : 
(see Appendix 1). Salcadts Hist bo uckgac siaban ib baiblabllod: ghaling Sephabian baa ihe 
ordering and grouping of selectors is unimportant. For example, the following name the same 
type: 


atomic_recordiiast, first, middie: string, age: int] 
atomic_record{last: string, age: int, first, middie: string] 


An atomic_record is created using a atomic_record constructor, see Section 6.2.11. 


For purposes of the certain operations, the the names of the selectors are ordered 
lexicographically. Lexicographic ordering of the selectors is the alphabetic ordering of the selector 
names written in lower case (based on the ASCII ordering of characters). 


Atomic_records use read/write locking to achieve atomicity. The locking rules are described in 
Section 2.2.2. it is an error if a process that is not in an action attempts to test or obtain a lock; 
when this happens the guardian running the process wil crash. As defined below, the only 
operation that (in the normal case) does not attempt to test or obtain a lock is the equa/ operation. 


In the following, let art = atomic_recordin,:t,, .... M,: {). 
Operations 
ar_gets_ar = proc (r1, 12: art) 
modifies r7. 
effects Obtains a write lock on r? and a read lock on 2, then sets each component of r7 to 
be the corresponding component of 12. 
get per art) returns (t,) 
effects Obtains a read lock on r and retums the component of r whose selector is n. There 
1s a get_ operation for each selector. 


set_n, = proc (r: art, @: t) 
modifies r. 
ettects Obtains a write lock on ¢ and modifies r by making the component whose selector is 
n,be e. There is a set_ operation for each selector. 
arer = proc (ar: art) returns (r. art) 
effects Obtains a read lock on ar and returns a record rwith the same state. 
r2ar = proc (r: art) returns (ar: art) 
effects returns an atomic_record ar with the same state as r. Obtains a read lock on ar. 
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equal = proc (r1, r2: art) returne (boo!) 
effects Returns true if r/ and /2 are the very same atomic_record object; otherwise returns 
false. No locks are obtained. 
similar = proc (r1, r2: art) returns (bool) signals (tailure(string)) 
requires each {has similar: proctype (|, t,) returns (bool) signais (failure(string)) 
effects Obtains a read lock on r1, then a read lock on /2 then 


: ely F 
comparison is done in lexicographic order of the selectors; H any comparison returns 
false, faise is returned immediately. if ai comparisons retum true, returns true. 


similar1 = proc (r1, r2: art) returns (bool) signals (fallure(string)) 
effects This operation is the same as similar, except that tSequa/ is used instead of 
t$similar. 
copy = proc (r: art) retums (res: art) signals (failure(string)) 


Sr) = eee art) returns (res: art) 
effects Obtains a read lock on r, then returns a new atomic_ record res containing the 


atomic_record res. 
transmit = proc (ar: rh eg tes (art) signals (failure(string)) 
effects Returns a new atomic containing a transmitted of each component of 


the new atomic_array. Any failure signal from tStranemit is immediately resignalied. 
This operation does not itself originate any failure signal. 


test_and_read = proc (ar: art) returns (bool) 
effects Tries to obtain a read lock on ar. H the lock is obtained, returns true; otherwise no 


returned. Even if false is returned, a subsequent attempt to obtain a read lock might 
succeed without waiting. 


test_and_write = proc (ar: art) returns (boo!) 
effects Tries to obtain a write lock on ar. If the lock is obtained, returns true; otherwise no 
lock is obtained and the operation retums falee. The operation does not “wait” for a lock. 
Even i# the executing action "knows" that a lock coukd be obtained, falee may be 
retumed. Even if falee is retumed, a subsequent attempt to obtain a write lock might 
succeed without waiting. 


can_read = proc (ar: ast} 
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1.14. Oneofs 
oneot! = date typein,: t,, .... hy: &) ls enaien_f,, ..., eee A, 1o_My, ..., 1_A,, velUO_f,, ..., VOIO_A,,, 
oav, van, cam ps cupy,. oamaanlt 


Overview 


A oneol is a tagged, discriminated union; that is, 9: 
set of aharnalives. ‘The lpel is called the gpa 2 


An inetantiation of erect has the form: 


eal py 


(eee Anpane 9 Pe Face eid La ants alot un imnaetaian: Gaieton weptatentans, bus tee 
ordering and grouping of tage je uninpertent. 


salad shies, © be theught of as “one of a 


A omoet to inanetente nb. smng:aestin in haabie-atiials Cindi. « wrest ie tents only & 08 ot 
the types of Rs date peste are aiomic. 


In the following, let ot = eneedin,: t,3..... 9: 43. 


Operations 


make_f, = proc (@: t) retumne (ot) 
i aac eat There is a make_ )_ operation tor each 


is_n, = proc (0: of returne (bool) 
effects 


Retwne true # the tag of o is A, ave rohune false. There is an ic operation for 
each selector. 
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value_n; = proc (0: ot) returns (t,) signals (wrong_tag) 
effects If the tag of o is n,, returns the value of o; otherwise signals wrong_tag. There is a 
value_ operation for each selector. 


O2v = proc (0: ot) returns (vit) 
effects Here vi is a variant type with the same selectors and types as of. Returns a new 
varia object with the same tag and value as o. 


v20 = proc (v: vi) returns (ot) 
effects Here vt is a variant type with the same selectors and types as of. Returns a oneof 
object with the same tag and value as v. 


equal = proc (01, ra pli a grr brie aan 
requires each /; has equal: proctype (|, t) returns (beol) signals (falure(string)) 
effects Returns true if 07 and 02 have the same tag and equal values as determined by the 
equal operation of thelr data pert’s type. Any feluure signal is resignaiied. 
This operation does not itself originate any failure signal. This operation is diviebie at the 


call of tS equal. 
similar = proc (01, 02: ot) returns (boo!) signals read psi 
requires each f; has similar: proctype (t,, t) returne (bool) signals (failure(string)) 


Orn BGA tee Gk ee ae ac ee 
the similar operation of their value's type. Any faiture signal is immediately resignaiied. 
This operation does not itself originate any failure signal. This operation is divisible at the 
call of tSsimilar. 


copy = proc (o: ot) returns (ot) signals (failure(string)) 
requires each {, has copy: proctype (t,) returns (t,) signals (failure(string)) 
effects Returns a oneot object with the same tag as o and containing as a value @ copy of 


signal. This operation is divisibie at the call of tScopy. 


transmit = proc (0: ot) returns (ot) signais (failure(string)) 
requires each {has transmit 
effects Returns a oneof object with the same tag as o and containing as a value a 
transmitted copy of o’s value. Any failure signal is immediately resignaiied. This 
operation does not itself originate any failure signal. 


11.15. Variants 


variant = data type [Nn,:t,, ..., n,: t,] Is make_n,, ..., make_n,, change_n,, ..., change_n,, 
is_N,, ..., i6_N,, Value_Ny,, ..., Value_N,, V_gets_v, v_gets_ 0, 
equal, similar, similar1, copy, copy1, transmk 


Overview 


A variant is a mutable, tagged, discriminated union. Its state is a oneof, that is, a labeled object, 
to be thought of as “one of" a set of alternatives. The label le called the tag part, and the object is 
Called the value (or data part). A variant aiso has an identity as an object. 


An instantiation of variant has the form: 
variant [ field_spec , ...] 
where 
fleld_spec ::= name, ... : type_actual 
(see Appendix |). Tags must be unique within an instarwation (ignoring capitalization), but the 
ordering and grouping of tags is unimportant. 


11.15 Variants 145 


Although there are variant operations for decomposing variant objects, they are usually 
decomposed via the tagcase statement, which is discussed in Section 10.14. 


In the following let vt = varlantin,: t,, ..., M,: t,). 
Operations 
make_n, = proc (e: t) returns (vt) 
effects 


Returns a new variant object with tag n, and value @. There is a make_ operation for 
each selector. 


change_n, = proc (v: vt, @: t) 
modifies v. 


effects Modifies v to have tag n; and value 6. There is a change__ operation for each 
selector. 


is_n, = proc (v: vi) returns (bool) 
effects Returns true if the tag of v is n; otherwise retums false. There is an is_ operation 
for each selector. 


value_n, = proc (v: vi) returns (t) signals (wrong_tag) 


effects It the tag of vis n, retums the value of v; otherwise signals wrong_tag. There is a 
value_ operation for each selector. 


v_gets v= prot. v2: vt) 

wadthee ¢ 

sriccke sicanns VS aniain he chs Go eee 
V_gets_0 = proc (v: vi, 0: ot) 

modifies v. 


effects Here of is the oneof type with the same selectors and types as vi. Modifies v to 
contain the same tag and value as o. 


equal = pl a A v2: vt) returns (bool) 
effects Returns true if v1 and v2 are the same variant object. 


similar = proc (v1, v2: vi) returns (bool) signals (failure(string)) 
requires each ¢ has similar: proctype (t, t) returns (bool) signals (failure(etring)) 
weg “cca e ce can cee Ma ae Ge esos ck ce he 
similar operation of their value’s type. Any failure signal is immediately resignaiied. This 
operation does not itself originate any fadure signal. This operation is divisible at the call 


of t$similar. 
similar1 = proc (v1, v2: vt) returns ees signais (falure(string)) 
requires each {has equal: proctype (t,, t,) retume (bool) signals (failure(string)) 


effects Same as similar, except that (Sequa/is used instead of iSsimilar. 


copy = proc (v: vs bac hy cna east 
requires each i has say: proses fy) rouares () sipaha Gubite(uiod)) 
effects Returns a variant object with the same tag as v and comaining as a value a copy of 
V8 value; Ee nee sae Woes et ae a te ce Any failure 
signal is immediately resignalied. This operation does not itself originate any failure 
signal. This operation is divisible at the call of tScopy. 


copy1 = proc i vt) returns (vt) 
effects R 


eturns a new variant object wkh the same tag as v and containing vs vaiue as its 
value. 
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transmk = proc (v: vt) returns (vt) signals (failure(string)) 
requires each {has transmit 
effects Retums a variam object with the same tag as v and containing as a value a 
transmitted copy of vs value. Any failure signal ie immediately resignalied. This 
operation does not itself originate any fadure signal. 


11.16. Atomic Variants 


atomic_variant = data type [n,: t,, ..., n,: t,] Ils make_n,, ..., make_n,, change_n,, ..., change_n,, 
av_gets_av, is_n,,...,is_n,, value_n,, ..., value_N,, av2v, v2av, 
equal, similar, similar1, copy, copy, traneme, 
test_and_read, test_and_write, can_read, can_write, read_lock, write_lock 


Overview 


An atomic_variant is a mutable, atomic, tagged, discriminated union. ls state is a oneof, that is, 
labeled object, to be thought of as “one of" a set of atematives. The label is called the fag part, 
and the object is called the vaive (or data part). An atomic_variant aiso has an identity as an 
object. 


An instantiation of atomic_variant has the form: 
atomic_variant [ field_spec, ... ] 
where 
field_spec :.= name, ... : type_actual 
(see Appendix |). Tags must be unique within an instantiation (ignoring capitalization), but the 
ordering and grouping of tage is unimportant. 


Although there are atomic_varient operations for decomposing atomic_variant objecis, they are 
usually decomposed via the tagtest statement or tagwalt statement, which are discussed in 
Section 10.15. 


In the following, let avt = atomic_variantin,: t,, .... M,: ty). 
Operations 
make_n, = proc (e: t) returns (av: avt) 


effects Returns a new atomic_variant object av with tag n; and value e. Obtains a read lock 
on av. There is a make_ operation for each selector. 


change_n, = proc (v: avt, e: t) 
modifies v. 
effects Obtains a write lock on v, then modifies v to have tag n; and value e. There is a 
change _ operation for each selector. 
av_gets_av = proc (v1, v2: avt) 
modifies v1. 


effects Obtains a read lock on v2 and then a write lock on v/, then modifies v7 to contain 
the same tag and value as v2. 


is_n; = proc (v: avt) returns (bool) 
effects Obtains a read lock on v, then returns true if the tag of v is n; otherwise returns 
false. There is an is_ operation for each selector. 


value_N, = proc (v: avt) returns (t) signais (wrong_tag) 
effects Obtains a read lock on v. Then, if the tag of vis n,, returns the value of v; otherwise 
signals wrong_tag. There is a value_ operation for each selector. 
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av2v = proc (av: avt) returns (v: vt) 
effects Here vt is a variant type with the same selectors and types as avi. Obtains a read 
jock on av and retums a variant v with the same state. 


v2av = proc (v: vt) returns (av: avt) 
etfects Here vt ie a variant type with the same selectors and types as avi. Returns an 
atomic_variant av with the same state as v. Obtains a read lock on av. 


equal = proc (v1, v2: avt) returns (boo!) 
ahosta Heusta teas 4:37 and eae eure eins ;_variamt object. No locks are 
obtained. 


similar = proc (v1, v2: avt) returns (bool) signals (failure(string)) 
requires each [has similar: proctype (t,, t) returns (veel) signals (failure(string)) 
effects Obtains read locks on v! and v2, in order, and then compares the objects; returns 
true if v? and v2 have the same tag and similar values as determined by the similar 
operation of their type. Any failure signal ls immediately resignailed. This does 
not itself originate any failure signal. This operation is divisible at the call of i$similar. 


similar! = proc (v1, v2: avt) returns (bool) signals (falture(string)) 
requires each f; has equal: proctype (t, t,) returns (beol) signals (failure(string)) 
effects Same as similar, except that {Sequa/ is used Instead of {Ssimilar. 


copy = proc (v: avt) returns (avt) signals (fallure(string)) 
requires each t,has copy: proctype (1) returne (t) signals (failure(string)) 
effects Obtains a read lock on v, then returns an atomic_variant object with the same tag as 
v and containing as a value a copy of Vs value; the copy is made using the copy 
operation of the value’s type. Any failure signal is immediately resignaiied. This 
operation does not itself originate any fadure signal. This operation is divisible at the call 
of tScopy. A read lock is obtained on the resu. 


copy1 = proc (v: avt) returns (avt) 
effects Obtains a read lock on v, then returns a new atomic_variant object with the same tag 
as v and containing vs value as kts value. A read lock is obtained on the result. 


transmik = proc (v: avi) returns (avi) signals (failure(string)) 
requires each 1 has tranemit 
effects Returns an atomic_variant object with the same tag as v and containing as a value a 
transmitted copy of vs value. Obtains a read lock on v. Sy ee a oan 
resignalied. This operation does not itself originate any failure signal. 


test_and_read = proc (av: avi) returns (bool) 
effects Tries to obtain a read lock on av. Hf the lock is obtained, returns true; otherwise no 


test_and_write = proc (av: avt) returns (boo!) 
effects Tries to obtain a write lock on av. If the lock is obtained, returns true; otherwise no 
lock is obtained and the operation returns false. The operation does not “wait” for a lock. 
Even i the executing action “knows” that a lock could be obtained, felee may be 
retumed. Even if false is returned, a subsequent attempt to obtain a write lock might 
succeed without waiting. 
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Retume true Hf a read lock could be obtained on av without waiting, otherwise 


even If true is returned, a subsequent attempt to obtain the lock may require waiting; and 
vb orca @ subsequent atiempt to obtein a read lock might succeed 
wit waking 


can_write = proc (av: avt) returns (bool) 
effects Returns true # a write look could be obtained on av wihout waiting, otherwise 


; may 
even i falee is returned, a subsequent attempt to obtain a write look might succeed 
without walting. 

read_lock = proc (av: avt) 

effects Obtains a read lock on av. 


write_lock = proc (av: avt) 
effects Obtains a write lock on av. 


1.17. Procedures and Kerators 


proctype = data type is equal, similar, copy 
Kertype = data type le equal, similar, copy 


Overview 


Procedures and Kerators are objects created by Se ee 
ee eee in a procedure or kerator heading; a 


proctype ([ type_spec., ... ]) fcurestl seta 
and an Kerator type specification hes the form: 


Kertype ([ type_spec , ... ]) [ yieids ] [ signais ] 


where 
returns se= fetus (type_spec, ...) 
yields sex yleids (type_spec, ...) 


signals se= signals (exception , ...) 


exception i:= name (type_spec, ...)] 


(see Appendix |). The first liet of type specifications describes the number, types, and onder of 
arguments. The retume or yielde clause the number, types, and order of the objects to be 
returned or ylekded. The signals clauses act es ai ee ce ae 


» ordering ot os 
For example, both of the following type specifications name the procedure type for string$aubst. 


proctype (string, int, int) retums (string) signals (bounds, negative_size) 
proctype (string, int, int) returns (string) signals (negative_size, bounds) 


Son Fad cacy cat fae ia et a rea aa aaa a ae i ai tales tl 
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Se ae 
see Section 9.8). Procedure and Kerator types are not tranemissible and are considered to be 
immutable and atomic in normal use. However, some uses of own data (see Section 12.7) in 
procedures and Kerators can violate this assumption. 
In the following operation descriptions, t stands for a proctype or itertype. 

Operations 


equal = proc (x, y: t) returns (bool) 
similar = proc (x, y: t) returns (boo!) 
effects These return true if and only if x and y are the same implementation of 

assy same abstraction, with the same parameters (see Section 12.6). 


copy = proc (x: t) returns (t) 
effects Returns x. 


11.18. Handlers and Creators 


handiertype = data type le equal, similar, copy, transmit 
creatortype = data type is equal, similar, copy, transmit 


Overview 


Handlers and creators are created by the Argus system. The type specification for a handler or 
creator contains most of the information stated In a handler or creator heading; a handler type 
specification has the form: 


handiertype ( [ type_spec , ... ]) [ retums ] [ signals ] 
and a creator type specification has the form: 


creatortype ( [ type_spec , ... ] ) [ returns ] [ signais ] 


where 
returns se returns (type_spec , ...) 
signals se= Signals (exception , ...) 


exception  ::= name (type_spec, «..) J 
(see Appendix |). The first list of type specifications describes the number, types, and order of 


The signals clause lists the exceptions raised by the handler or creator; for each exception name, 
the number, types, and order of the objects to be retumed are also given. All names used in a 
signals clause must. be unique; none can be unavailable or failure, which have a pre-defined 
meaning for remote calls (see Section 8.3). The ordering of exceptions is not important. 


Creators are created by compiling modules, and handlers are created as a side-effect of guardian 
creation. Handlers and creators are transmissible and are considered to be immutable and atomic 
in normal use. Certain uses of own data in handlers can violate this assumption. 


In the following operation descriptions, f stands for a handilertype or creatortype. 
Operations 


equal = proc (x, y: t) returns (bool) 
similar = pl al (x, y: t) returns (bool) 
effects These operations retum true if and only if x and y are the same object (see Section 

12.6 for an exact definition for the Case of creators in guardian generators). 
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copy = proc (x: t) returns (t) 
transmit « proc (x: t) returns (t) 
effects Retums x. 


lI.19. Anys 
any = data type Is create, force, is_type 
Overview 


An object of type any contains a type T and an object of type 7. Anys are immutable and are not 
transmissible. Anys are atomic only if thelr contained object is atomic. 


Operations 


create = proc[T: type] (contents: T) returns (any) 
effects Returns an any object containing contents and the type T. 


force = vale re! (thing: = returns (T) signals (wrong_type) 
if thing containe an object of a type included in type 7, then that object is returned; 


hate ng type is signaiied. 
is ene os Se ee any) returns (bool) 
if thing contains an object of a type included in type 7, then true is retumed; 
o caewaa ike Ward 


11.20. Images 
image = data type is create, force, is_type, copy, transmit 
Overview 


An object of type image is the value of an arbitrary transmissible type. See Section 14 for more 
details. Images are immutable, atomic, and transmissible. 


Operations 
create = proc{[T: type] (contents: T) returns (image) signals (failurestring) 
requires T has tranemit 
effects Returns an image Obtained from contents via the encode operation of T. 


object 
Resignais any failure signal raised by T's encode operation. 
force = proc{T: type] (thing: nage) returns (T) signals (wrong_type, fallure(string)) 
requires T hae tranemit 
eee ae ee ei ee T, then that object is extracted 


using the decode operation of T and returned. Otherwise wrong_ type is signalled. 
Resignals any failure signal raised by T's decode operation. 


is_type = Pro peel Ai image) returns (boo!) 
requires T 


elects fing encodes an obfect of & ype ced ype Then re I rues 
otherwise, faiee is returned. 


copy = proc (thing: Image) returns (image) 
transmit = proc (thing: image) returns (image) 
effects Retums thing. 
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11.21. Mutexes 
mutex = data type(t: type] is create, set_value, get_value, changed, equal, similar, copy, transmit 
Overview 
A mutex is a mutable container for an object of type ft. A mutex also has an identity as an object. 
An object of type mutex[t] provides mutual exclusion for process synchronization, and aliows 


explicit control over how information contained in the mutex is written to stable storage (see 
Section 15.1). 


The seize statement is used in order to gain possession of a mutex. See section 6.7. 


Although mutex objects are mutable, sharing among mutex objects is usually wrong, because the 
contained object should only be accessible through the mutex. Hence there is no copy! 
operation, since this would introduce sharing, and there is no similar! operation to check for 
sharing (see Section 6.7). 


Operations 


create = proc (thing: t) returns (mutex{t]) 
ettects Returns a new mutex object containing thing. 


set_value = proc (container: mutex{t], contents: t) 
modifies container. 
effects Modifies container by replacing kts comained object with contents. 


get_value = proc (container: mutex{ti]) returns (t) 
etfects Returns the object contained in container. 


changed = proc (container: mutex{t]) 

effects Informs the Argus system that the calling action requires the contents of container to 
be copied to stable storage by the time the action commits, provided container is 
accessible from a stable variable. it is a programming error if a process that is not 
running an action calis thie operations, and if this is done the guardian will crash. 


equal = proc (m1, m2: mutex{t]) returns (boo!) 
effects Returns true if and only if m7 and m2 are the same object. 


similar = proc (m1, m2: mutex{t]) retums (boo!) signals (failure(string)) 


requires t has similar: proctype(t, t) returne(boo! (fallure(string)) 

effects Seizes m1, then seizes m2, and calls to determine its result; any failure 
signal is immediately resignalied. Possession of both mutexes is retained until Ssimilar 
terminates. 


Copy = proc (m1: mutexjt]) returns (m2: mutex{t}) signals (falture(string)) 
requires t has (laliure(string)) 


effects Seizes m1, then calle f$copy to make a copy which it places in the new mutex object 
m2. OY eee nen onreres: Possession of m1 is retained until 
f$copy terminates 

tranemi = proc (m1: mutex{t]) returns (mutex{t]) signels (failure(string)) 

requires t has tranemit 

effects Seizes m1, and retums a new mutex containing a transmitted copy of the contained 
object. Any failure signal is immediately resignaiied. Possession of m1! is retained until 
Stransmk terminates. 
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Appendix Ill 
Rules and Guidelines for Using Argus 
This appendix collects the rules and guidelines that should be followed when programming in Argus. 
Following these rules makes seize statements meaningful, actions atomic, and so on. In some rare 
cases there may be valid reasons for violating these guidelines, but doing so greatly increases the 
difficulty of building, debugging, and running the resulting system. 


All of the rules listed in this appendix are based on information appearing elsewhere in the manual. 
Each rule is followed by a brief rationale, including a reference to the section of the manual from which it 
is drawn. 


lli.1. Serializability and Actions 
e Actions should share only atomic objects. 
Rationale: Actions that share non-atomic data are not necessarily serializable. [Section 2.2.2] 


e A subaction that aborts should not return any information obtained from data shared with other 
concurrent actions. 


Rationale: Returning such data may violate serializabilay. [Section 2.2.1] 
e A nested topaction should be serializable before its parent. This is true if either 


1. the nested topaction performs a benevolent side effect (a change to the state of the 
representation that does not affect the abstract state), or 


2. all communication between the nested topaction and is parent is through atomic objects. 
Rationale: Other uses may violate serializabilty. [Section 2.2.3] 


e The creation or destruction of a guardian must be synchronized with the use of that guardian via 
atomic objects such as the catalog. 


Rationale: Otherwise serializability may be violated. [Section 10.18] 


111.2. Actions and Exceptions 


e If an exception raised by a call should not commit an action, the exception must be handled within 
that action. 


Rationale: tf an exception raised within an action body is handied outside the action, the implicit flow of 
control outside of the action will commit the action. [Section 11.5] 
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111.3. Stable Variables 
e Stable variables should denote resilient data objects. 


Rationale: Only data objects that are (reachable from the stable variables and) resilient are written to 
stable storage when a topaction commits. (This can be ensured by having stable variables only denote 
objects of an atomic type or objects protected by mutex.) Non-resilient objects stored in stable variables 
are only written to stable storage when the guardian is created. [Section 13.1] 


e If a bound procedure or kerator will be accessible from a stable variabie, 
1. the procedure or iterator being bound must be atomic and 


2. only atomic objects should be bound as arguments. 


Rationale: The bound procedure or iterator may be stored in stable storage, and non-atomic data is 
only written to stable storage once. [Section 9.8] 


lll.4. Transmission and Transmissibility 
e An abstract type’s encode and decode operations shoukil not cause side effects. 


Rationale: The number of calis to an encode or decode operation is unpredictable, since arguments or 
results may be encoded and decoded several times as the system tries to establish communication. in 
addition, verifying the correctness of transmission is easier if encode and decode are simply 
transformations to and from the extemal representation. [Section 14.3] 


e If the naming relation among objects to be transmitted Is cyclic (e.g., a circular list) then encode and 
decode must be implemented in one of two ways: 


1. The internal and external representation types must be identical, and encode and decode 
return their argument without modifying or accessing i, or 


2. The external representation object must be acyclic. 
Rationale: A circular extemal representation may cause decode to fail. [Section 14.4] 


e Objects that share other objects should be bound into a handler or creator in the same bind 
expression. 


Rationale: Sharing is only preserved among objects bound at the same time. [Section 9.8] 

111.5. Mutex 
e Mutual exclusion or atomic data should be used to synchronize access to all shared objects. 
Rationale: tn the presence of concurrency, any interleaving of indivisible events is possible. Without 


synchronization mechanisms, this concurrency will be visible to programs, significantly complicating 
coding and testing. [Section 8] 
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All modifications to mutex objects should be made inside seize statements. 


Rationale: The system will gain possession of a mutex object before writing K to stable storage; thus, 
seizing a mutex in order to modify it will prevent the system from copying a mutex object when it is in an 
inconsistent state. This also prevents other processes from seeing inconsistent data [Section 15.2 and 
Section 15.1] 


e Nested seizes should be avoided when pause is used, and peuse must be avoided when nested 
seizes are used. 


Rationale: A pause in a nested seize does not actually release possession of the mutex object. 
[Section 10.17] 


e If an object is referred to by a mutex object, k should not be referred to by any other object, nor 
should it be denoted by a variable except when in possession of the containing mutex. 


Rationale: If an object contained in a mutex can be reached by a method other than seizing the mutex, 
the mutual exckision property of the mutex is undermined. [Section 6.7] 


e No activity that is likely to take a long time should be performed while in a seize statement. in 
particular, programe should not make handier calls or wait for locks on atomic objects while in possession 
of a mutex. 


Rationale: Waiting for a lock while in a mutex is likely to cause a deadiock with other actions or 
between the action holding the mutex and the Argus system. [Section 15.3] 


e Mutex objects should not share data with one another, unless the shared data is atomic or mutex. 


Rationale: Sharing of non-atomic objects between mutex objects is not preserved when the mutexes 
are written to stable storage. [Section 15.3] 


e Mutex[§$changed must be called after the last modification (on behalf of some action) to the 
contained object of a mutex. 


Rationale: The Argus system is free to copy the mutex to stable storage as soon as mutex] &$changed 
has been called. Changes after the last call to mutex{§$changed but before topaction commit may not 
be written to stable storage. [Section 15.3] 


e Mutex[§$changed should be called even if the mutex object changed is not accessible from the 
stable variables. 


Rationale: \n a scenario where the object was accessible, becomes inacoessible, then becomes 
accessible again, it is possible that stable storage would not be updated properly if this rule were not 
foliowed. The system guarantees that no problems with updating stable storage will arise if 
mutex[§$changed is always called after the last modification to the object. [Section 15.3] 
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e An atomic type implemented with a representation consisting of several mutex objects should use 
separate topactions to ensure that the mutexes are written to stable storage in an order that preserves 
the correctness of the representation. 


Rationale: Mutexes are written to stable storage incrementally. Sometimes, subtie timing problems 
can be caused by incremental writing if this rule is not followed. [Section 15.3] 


111.6. User-Defined Atomic Objects 

e If an atomic object X of type T provides operations O, and O,, and action A has executed O, but not 
yet committed, then operation O, can be performed by a concurrent action B only if O, and O, commute: 
given the current state of X, the effect (as described by the sequential specification of 7) of performing 
O,, then O, is the same as performing O,, then O,. “Effect” includes both results returned and the 
(abstract) state modified. 


Rationale: There are two concurrency constraints for user-defined atomic objects: 


1. An action can observe the effects of other actions only if those actions committed relative to 
the first action. 


2. Operations executed by one action cannot invalidate the results of operations executed by 
a concurrent action. 


Two operations (or sequences of operations) that commute in their effect on the abstract state of X may 
be permitted to run concurrently, even if they do not commute in their effect on the representation of X. 
This distinction between an abstraction and its implementation is crucial in achieving reasonable 
performance. [Section 15.4] 


e If a user-defined atomic object is accessible from the stable variables of some guardian, # should be 
written to stable storage whenever an action that modifies it cormmits to the top. 


Rationale: A user-defined atomic type that is not written to stable storage on topaction comma will not 
be resitient. [Section 15.2] 


¢ The form of the rep for a user-defined atomic type should be one of the following possibilities. 
1. The rep is itself atomic. Note that mutex is not an atomic type. 
2. The rep is mutex{{ where ¢ is a synchronous type. For example, t could be atomic, or it 


could be the representation of an atomic type, if the operations on the this fictitious atomic 
type are coded in-line 90 that the entire type behaves atomically. 


3. The rep is an atomic collection of mutex types containing synchronous types. 


4. The rep is a mutable collection of synchronous types, and objects of the representation 
type are never modified after they are initialized. That is, mutation may be used to create 
the initial state of such an object, but once this has been done the object must never be 
moditied. 


Rationale: \n any other case it will be impossible to guarantee the resilience or serializability of the 
type’s objects independently of how they are used. [Section 15.3] 
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lll.7. Subordinate Where Clauses 

e A where clause requirement on a cluster as a whole should be used whenever the actual parameters 
make some difference in the abstraction. For example, in a set cluster, the type parameters equal 
operation must be required by the cluster as a whole, in order to preserve type safety and the 
representation invariarm. 


Rationale: Argus assumes that requirements that are not placed on the cluster as a whole do not 
affect the semantics of the abstraction or the represertation. [Section 12.6] 
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Appendix IV 
Changes from CLU 
This appendix lists the changes made to Argus that are not upward compatible with CLU, that is, those 
which are not merely additions to CLU and that would cause a CLU program to be iiegal or to run 
differently. 


IV.1. Exception Handling 

Unlike CLU, which propagated unhandled exceptions (by turning them into failure exceptions) and gave 
the failure exception special status, unhandled exceptions in Argus are considered errors and always 
cause a crash of the guardian, and failure is not given special status. All exceptions signatied in a 
procedure, iterator, handier, or creator must be declared in the routine’s header, and there are no implicit 
resignals of failure exceptions. See Section 11.6 for details. 


IV.2. Type Any 

The type any is now a type like any other type, with parameterized routines force, create, and is_type. 
Thus the CLU manual’s notion of "type inclusion" is no longer necessary (but there is a new notion of type 
inclusion in Argus, see Section 6.1). The any$force routine only signals “wrong_type" if the any object’s 
underlying type is not included in the type parameter given, but the type of the result of any$force is its 
type parameter. The any$is_type routine returns false # the any object's underlying type is not included 
in the type parameter given. The CLU reserved word “force" was eliminated from Argus, and the creation 
of an any object is never implicit in an assignment in Argus. 


IV.3. Built-in Types 
Several changes to the interfaces of the built-in types were necessitated by the changes to exception 
handling. Specifically, the following changes were made to the built-in types. 


1. The string operations concat, append, s2ac, ac2s, 82sc, and ac2s, can now ail signal Himits. 
A string eral that would be too large to represent will not be compiled. 


2. The sequence operations fill, fil_copy, addh, addi, and concat can now ail signal limits. A 
sequence constructor that would be too large to represent will not be compiled. 


3. The array (and atomic_array) operations create, predict, set_low, fill, fill_copy, addh, and 
add! can now all signal limits. An array constructor that cannot be legally represented will 
either not be compiled (if this can be detected at compile time) or will signal limits. 


4. The copy operations of the structured built-in type generators, and the fii_copy operations 
of sequence and array (and atomic_ array), allow the copy operations of their type 
parameters to have a failure(string) exception. They will resignal such a failure exception. 
(Note that the type inclusion rule allows a type parameter to be used even if its copy 
operation does not have exceptions.) 


5. The similar operations of the built-in structured type generators allow the similar operations 
of their type parameters to have a failure(string) exception. They will resignal such a failure 
exception. 


6. The equal operations of the type generators sequence, struct, and oneof, and the similar! 
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operations of the type generators array, record, and variant (and their atomic 
counterparts), allow the equa/ operation of their type parameters to have a fasure(string) 
exception. They will resignal such a failure exception. 


7. The elements iterator and the similar and similar! procedures of the type generator 


array 
(and atomic_array) will raise a faiiure(etring) exception i the array argument is mutated in 
such a way as to cause a bounds exception when an element is fetched. 


IV.4. Type Inclusion 
Type inclusion (the new notion, see Section 6.1) is used in all contexts, including the decis of except 
and tagcase statements, where CLU had previously required type equailty. 


iV.5. Where Clauses 

CLU had syntax in the where clause (specifically the production for op name) that allowed one to 
require an instantiation of a type parameter's generator. This Iktle used feature has been superseded by 
the mechanism described in Section 12.6. 


IV.6. Uninitialized Variables 
An uninitialized variable reference error is defined to cause a crash of the guardian, rather than raising 
a failure exception, which could conceivably be caught. 


IV.7. Lexical Changes 
Several new reserved words were added. In addition, the semicoion (;) was banished from the ita. 


IV.8. Input/Output Changes 

The input/output data types (file_name, stream, sc} Ncbriasi ahd thes srany puinoeehined awerised i 
appendix Ill of the CLU manual are not furnished by the Argus system. Our current implementation of 
Argus provides a keyboard cluster for input and a petream cluster for output. in addition, most of the 
built-in types currently have print operations defined, for pretty-printing objects onto pstreams. These I/O 
mechanisms, however, are still experimental, and so are not documented in this reference manual. 
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